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PREFACE 


The McDonnell Douglas Astronautics Company has been engaged in a Space 
Station Data System Analysis/Architecture Study for the National Aeronautics 
and Space Administration, Goddard Space Flight Center. This study, which 
emphasized a system engineering design for a complete, end-to-end data system, 
was divided Into six tasks: 


Task 

1 . 

Functional Requirements Definition 

Task 

2. 

Options Development 

Task 

3. 

Trade Studies 

Task 

4. 

System Definitions 

Task 

5. 

Program Plan 

Task 

6. 

Study Maintenance 


McDonnell Douglas was assisted by the Ford Aerospace and Communications 
Corporation, IBM Federal Systems Division and RCA In these Tasks. The Task 
Inter-relationship and documentation flow are shown in Figure 1. 

This report was prepared for the National Aeronautics and Space 
Administration Goddard Space Flight Center under Contract No. NAS5-28082 


Questions regarding this report should be directed to: 

Glen P. Love 
Study Manager 

McDonnell Douglas Astronautics Company 
Huntington Beach, CA 92647 
(714) 896-2292 


preceding page bunk not filmed 


iii 



oo 

CD 

UO 


CD 

I 

> 


HI 



D 

O 

LU 


3 

O) 



o 

o 

Q 

< 

(0 

Q 

(0 

</> 




iv 















Task 3 Volume II 
CONTENTS 


Page 

IX SOFTWARE DEVELOPMENT TEST AND INTEGRATION CAPABILITY 9-1 

1.0 INTRODUCTION 9-3 

1.1 Background 9-3 

1.2 Issues 9-3 

1.3 Trade Study Criteria 9-4 

1.4 Application Option Papers 9-6 

1.5 Alternatives 9-7 

2.0 METHODOLOGY 9-8 

3.0 RESULTS 9-8 

3.1 Basic Summary 9-8 

3.2 Background Information 9-10 

3.3 Options Comparisons 9-17 

4.0 CONCLUSIONS 9-19 

5.0 REFERENCES 9-20 

X FAULT TOLERANT COMPUTING 10-1 

1.0 INTRODUCTION 10-3 

1.1 Background 10-3 

1.2 Issues 10-4 

1.3 Trade Study Criteria 10-4 

1.4 Applicable Options 10-5 

1.5 Alternatives 10-5 

2.0 METHODOLOGY 10-7 

3.0 RESULTS 10-8 

3.1 Summary 10-8 

3.2 Related Topics 10-8 

3.3 Decision Matrices 10-11 

4.0 CONCLUSIONS, RECOMMENDATIONS AND REMAINING ISSUES 10-11 

5.0 REFERENCES 10-18 

XI SPACE QUALIFIED COMPUTERS 11-1 

1.0 TRADE STUDY DEFINITION 11-1 

1.1 Purpose of Trade Study 11-1 

1.2 Background 11-1 

1.3 Issues H _5 

1.4 Trade Study Criteria 11-7 

2.0 TRADE STUDY METHODOLOGY 11-11 

3.0 TRADE STUDY DISCUSSION AND RESULTS 11-12 

3.1 Standardization vs Commercial Instruction Set 

Architectures 11-12 

3.2 Special Purpose vs Standard Architectures 11-15 

3.3 Radiation Qualification LEvel 11-22 

3.4 Fault Tolerance 11-29 

3.5 Imbedded vs Stand Alone SDP Options 11-33 

4.0 CONCLUSIONS/OPEN ISSUES 11-33 


V 



XII DISTRIBUTED DATA BASE MANAGEMENT SYSTEM 

1.0 INTRODUCTION 

1.1 Background 

1.2 Issues 

1.3 Trade Study Criteria 

1.4 Applicable Options 

1.5 Alternatives 

2.0 METHODOLOGY 

3.0 RESULTS 

3.1 Data Base Segmentation 

3.2 Space/Ground Partitioning 

3.3 SSP DB Segment Characterization 

4.0 CONCLUSION, RECOMMENDATIONS AND REMAINING ISSUES 

4.1 Space Station Operational Data Base 

4.2 Remaining Issues 

5.0 REFERENCES 
APPENOIX A 


XIII SYSTEM INTEGRATION TEST AND VERIFICATION (SITV) TRADE STUDY 


1 .0 


2.0 

3.0 


TRADE STUDY DEFINITION 

1.1 Purpose of Trade Study 

1.2 Background 

1.3 Issues 

1.4 Trade Study Criteria 
TRADE STUOY METHODOLOGY 

TRADE STUDY DISCUSSION AND RESULTS 

3.1 Ground Integration Effort for the SSDS 

3.2 Ground Integration Effort for the Launch Modules 

3.3 Pre-Launch End-to-End SSDS Verification Effort 

3.4 Pre-Launch Integration Effort for Growth Phase 
Elements 


XIV CREW WORKSTATION 

2.0 CREW WORKSTATION TRADE STUDY 

2.0. 1 Displays Selection 

2.0. 2 Color Display vs Monochrome 

2.0. 3 Input Controls Selection 

2.0. 4 Caution and Warning System Selection 

XV MASS STORAGE 

1. Reason for Trade Study 

2. Background 

3. Issues 

4. Trade Study Criteria 

5. Expected Results 

6. Methodology 

7. Trade Study Discussion and Results 

8. Conclusions 


12-1 

12-3 

12-3 

12-5 

12-9 

12-9 

12-10 

12-28 

12-30 

12-30 

12-35 

12-39 

12-40 

12-42 

12-43 

12-46 


13-1 

13-1 

13-1 

13-1 

13-9 

13-10 

13-11 

13-12 

13-12 

13-14 

13-18 

13-21 


14-1 

14- 3 
14-12 
14-24 
14-29 

14- 41 

15- 1 

15-3 

15-3 

15-7 

15-7 

15- 10 
15-10 
15-12 
15-51 


XVI COMMAND AND RESOURCE MANAGEMENT 

1.0 TRADE STUDY DEFINITION 

1.1 Reason for Trade Study 

1.2 Background 

1.3 Candidate System Options 

1.4 Issues 

1.5 Trade Study Criteria 

2.0 METHOOOLOGY 

3.0 RESULTS 

4.0 CONCLUSIONS, RECOMMENDATION AND ISSUES 

5.0 REFERENCES 

XVII SPACE COMMUNICATIONS 

1.0 INTRODUCTION 

2.0 GROUND-SPACE ARCHITECTURE 

2.1 Ground to Space Architecture Options 

2.2 Conclusion 

3.0 DOWNLINK TRANSMISSION OPTIONS 

3.1 Tradeoff Considerations 

3.2 Conclusions 

4.0 UPLINK TRANSMISSION OPTIONS 

4.1 Channel Allocation Scheme No. 1 

4.2 Channel Allocation Scheme No. 2 

4.3 Conclusion 

5.0 INTERNAL (PLATFORM) ARCHITECTURE OPTIONS 

5.1 Bus Network vs Switched Distribution Structures 

5.2 Bus/Network Options 

5.3 Conclusions 


vii 


16-1 

16-3 

16-3 

16- 3 
16-6 
16-6 

16-12 

16-16 

16-16 

16- 19 
16-20 

17- 1 

17-1 

17-2 

17-2 

17-7 

17-8 

17-9 

17- 12 
17-12 
17-13 
17-13 
17-13 
17-13 
17-15 
17-15 
17-17 



GLOSSARY 


A 

Automatic 

A&R 

Automation and Robotics 

A/A 

Analysis/Architecture 

A/D 

Advanced Development 

A/L 

Airlock 

A/N 

Alphanumeric 

AC&S 

Attitude Control System 

ACA 

Attitude Control Assembly 

ACO 

Administrative Contracting Officer 

ACS 

Attitude Control and Stabilization 

ACS/CON 

Attitude Control System/Communications 

ACTS 

Advanced Communications Technology Satellite 

AD 

Ancillary Data 

AD 

Advanced Development 

ADOP 

Advanced Distributed Onboard Processor 

ADP 

Advanced Development Plan 

AFOSR 

Air Force Office of Scientific Research 

AFP 

Advanced Flexible Processor 

AFRPL 

Air Force Rocket Propulsion Laboratory 

AGC 

Automatic Gain Control 

AGE 

Attempt to Generalize 

AI 

Artificial Intelligence 

AIE 

Ada Integrated Environment 

AIPS 

Advanced Information Processing System 

AL1 

Air Lock One 

ALS 

Alternate Landing Site 

ALS/N 

Ada Language System/Navy 

ANIC 

Automated Management Information Center 

ANSI 

American National Standards Institute 

AOS 

Acquisition of Signal 

AP 

Automatic Programming 

APD 

Avalanche Photo Diode 

APSE 

Ada Programming Support Environment 

ARC 

Ames Research Center 




P^CEDfNQ PAGE BLANK UQT FILMED 




ART 

ASCII 

ASE 

ASTROS 

ATAC 

ATC 

ATP 

ATPS 

ATS 

AVMI 

AWSI 

B 

BARC 

BB 

BER 

BIT 

BITE 

BIU 

BIU 

BIU 

BMD 

BTU 

BW 

C 


C&OH 

C&T 

C&T 

C&M 

C/L 

CA 

CAD 

CAE 

CAIS 

CAM 


Automated Reasoning Tool 

American Standard Code for Information Exchange 

Airborne Support Equipment 

Advanced Star/Target Reference Optical Sensor 

Advanced Technology Advisory Committee 

Air Traffic Control 

Authority to Proceed 

Advanced Telemetry Processing System 

Assembly Truss and Structure 

Automated Visual Maintenance Information 

Adoptive Wafer Scale Integration 

Bridge 

Block Adaptive Rate Controlled 

Breadboard 

Bit Error Rate 

Built-In Test 

Built-In Test Equipment 

Buffer Interface Unit 

Bus Interface Unit 

Built-In Unit 

Ballistic Missile Defense 

British Thermal Unit 

Bandwidth 

Constrained 

Command and Control 

Command, Control, and Communication 

Command, Control, Communication, and Intelligence 

Communications and Data Handling 

Communication and Tracking Subsystem 

Communications and Tracking 

Control and Warning 

Checklist 

Customer Accommodation 
Computer-Aided Design 
Computer-Aided Engineering 
Common APSE Interface Set 
Computer-Aided Manufacturing 



CAMAC 

CAP 

CASB 

CASE 

CATL 

CBO 

CBEMA 

CCA 

CCB 

CCB 

CCC 

CCD 

CCITT 

CCITT 

CCMS 

CCR 

CCSDS 

CCTV 

cd/H 2 

CDG 

CDMA 

CDOS 

CDR 

CDS 

CE 

CEI 

CER 

CFR 

CFS 

CG 

CIE 

CIL 

CIU 

CLAN 

CM 

CM 

CMDB 


Computer Automatic Measurement and Control 
Crew Activities Plan 
Cost Accounting Standard Board 
Common Application Service Elements 
Controlled Aceptance Test Library 
Commerce Business Dally 

Computer and Business Equipment Manufacturing Association 

Cluster Coding Algorithm 

Contractor Control Board 

Configuration Control Board 

Change and Configuration Control 

Charge-Coupled Device 

Consultive Committee for International Telegraph and Telephone 

Coordinating Committee for International Telephony and Telegraphy 

Checkout Control and Monitor System 

Configuration Change Request 

Consultative Committee for Space Data System 

Closed-Circuit Television 

Candelas per square Meter 

Concept Development Group 

Code Division Multiple Access 

Customer Data Operations System 

Critical Design Review 

Control Data Subsystem 

Conducted Emission 

Contract End-Item 

Cost Estimating Relationship 

Code of Federal Regulations 

Cambridge File Server 

Center of Gravity 

Customer Interface Element 

Critical Item List 

Customer Interface Unit 

Core Local Area Network 

Configuration Management 

Center of Mass 

Configuration Management Data Base 


XI 



CHG 

Control Moment Gyro 

CMOS 

Complementary Metal-Oxide Semiconductor 

CMS 

Customer Mission Specialist 

CMU 

Carnegle-Mellon University 

CO 

Contracting Officer 

COF 

Component Origination Form 

COL 

Controlled Operations Library 

COMM 

Commercial Missions 

COP 

Co-orbital Platform 

COPCC 

Coorbit Platform Control Center 

COPOCC 

COP Operations Control Center 

COTS 

Commercial Off-the-Shelf Software 

CPCI 

Computer Program Configuration Item 

CPU 

Central Processing Unit 

CQL 

Channel Queue Limit 

CR 

Compression Ratio 

CR 

Change Request 

CR&O 

Contract Research and Development 

CRC 

Cyclic Redundancy Checks 

CRF 

Change Request Form 

CRSS 

Customer Requirements for Standard Services 

CRT 

Cathode Ray Tube 

CS 

Conducted Susceptibility 

CSD 

Contract Start Date 

CSOL 

Charles Stark Draper Laboratory 

CSMA/CD/TS 

Carrier-Sense Multiple with Access/Colllslon Detection and Time 
Slots 

CSTL 

Controlled System Test Library 

CTA 

Computer Technology Associates 

CTE 

Coefficient of Thermal Expansion 

CUI 

Common Usage Item 

CVSD 

Code Variable Slope Delta (Modulation) 

CWG 

Commonality Working Group 

D&B 

Docking and Berthing 

DAOS 

Digital Audio Distribution System 

DAIS 

Olgltal Avionics Integration System 

DAR 

Defense Acquisition Regulation 


xii 



OARPA 

Defense Advanced Research Projects Agency 

OB 

Oata Base 

DBA 

Data Base Administrator 

OBNL 

Data Base Manipulation Language 

DBMS 

Oata Base Management System 

DCAS 

Oefense Contract Administrative Services 

DCDS 

Distributed Computer Design System 

OCR 

Data Change Request 

DDBM 

Distributed Data Base Management 

DOC 

Discipline Data Center 

DOT&E 

Design, Development, Testing, and Engineering 

DEC 

Digital Equipment Corp. 

DES 

Data Encryption Standard 

DFD 

Data Flow Diagram 

D6E 

Display Generation Equipment 

DHC 

Data Handling Center 

DID 

Data Item Description 

DIF 

Data Interchange Format 

DMA 

Direct Memory Access 

DNS 

Data Management System 

DoD 

Department of Defense 

DOMSAT 

Domestic Communications Satellite System 

DOS 

Distributed Operating System 

DOT 

Department of Transportation 

DPCM 

Differential Pulse Code Modulation 

DPS 

Data Processing System 

DR 

Discrepancy Report 

DR 

Data Requirement 

DRAM 

Dynamic Random-Access Memory 

DRD 

Design Requirement Document 

DS&T 

Development Simulation and Training 

DSDB 

Distributed System Data Base 

DSDL 

Data Storage Description Language 

DSDS 

Data System Dynamic Simulation 

DSIT 

Development, Simulation, Integration and Training 

DSN 

Deep-Space Network 

DTC 

Design to Cost 


xiii 



OTC/LCC 

DTG 

E/R 

EAOI 

ECC 

ECLSS 

ECMA 

ECP 

ECS 

EOF 

EEE 

EHF 

EHSI 

EIA 

EL 

EM 

EMC 

EMCFA 

ENE 

EMI 

EMR 

EMS 

EMU 

EMUOS 

EO 

EOL 

EOS 

EPA 

EPS 

ERBE 

ERRP 

ESR 

ESTL 

EVA 

F/T 

FACC 

FADS 


Design to Cost/Life Cycle Cost 
Design To Grow 
Entlty/Relatlonshlp 

Electronic Attitude Direction Indicator 
Error Correction Codes 

Environmental Control and Life-Support System 
European Computers Manufacturing Assoc. 

Engineering Change Proposals 

Environmental Control System 

Engineering Data Function 

Electrical, Electronic, and Electromechanical 

Extremely High Frequency 

Electronic Horizontal Situation Indicator 

Electronic Industry Association 

Electroluminescent 

Electromagnetic 

Electromagnetic Compatibility 

Electromagnetic Compatibility Frequency Analysis 

Earth Mean Equator 

Electromagnetic Interference 

Executive Management Review 

Engineering Master Schedule 

Extravehicular Mobility Unit 

Extravehicular Maneuvering Unit Decontamination System 

Electro-optic 

End of Life 

Earth Observing System 

Environmental Protection Agency 

Electrical Power System 

Earth Radiation Budget Experiment 

Equipment Replacement and Refurbishing Plan 

Engineering Support Request 

Electronic Systems Test Laboratory 

Extravehicular Activity 

Fault Tolerant 

Ford Aerospace and Communications Corporation 
Functionally Automated Database System 


XIV 



FAR 

FCA 

FCOS 

FCR 

FOOI 

FDF 

FDMA 

FEID 

FETHOS 

FF 

FFT 

FIFO 

FIPS 

fl 

FM 

FMEA 

FMECA 

FO 

FO/FS/R 

FOC 

FODB 

FOOS 

FPR 

FQR 

FSD 

FSE 

FSED 

FSIM 

FSW 

FTA 

FTMP 

FTSC 

GaAs 

GaAsP 

GalnP 

GaP 

GAPP 


Federal Acquisition Regulation 
Functional Configuration Audit 
Flight Computer Operating System 
Flight Control Rooms 
Fiber Distributed Oata Interface 
Flight Dynamics Facility 
Frequency-Division Multiple Access 
Flight Equipment Interface Device 

Floating Gate Election Tunneling Metal Oxide Semiconductor 
Free Flier 

Fast Fourier Transform 
First In First Out 

Federal Information Processing Standards 

foot lambert - Unit of Illumination 

Facility Management 

Failure Modes and Effects Analysis 

Failure Node Effects and Criticality Analysis 

Fiber-Optics 

Fal 1 -Operational /Fa 1 1 Safe/Res tor able 

Fiber-Optic Cable 

Fiber-Optic Data Bus 

Fiber Optic Demonstration System 

Federal Procurement Regulation 

Formal Qualification Review 

Full-Scale Development 

Flight Support Equipment 

Full Scale Engineering Development 

Functional Simulator 

Flight Software 

Fault Tree Analysis 

Fault Tolerant Multi-Processor 

Fault Tolerant Space Computer 

Gallium Arsenide 

Gallium Arsenic Phosphorus 

6a111um Indium Phosphorus 

Gallium Phosphorous 

Geometric Arithmetic Parallel Processor 


XV 



Gbps 

GBSS 

GEO 

GEP 

GFC 

GFE 

6FP 

6FY 

GIDEP 

CMM 

onn 

GMS 

GMT 

GMW 

GN&C 

GPC 

GPP 

GPS 

GRO 

GSC 

GSE 

GSFC 

GTOSS 

H/W 

HAL 

HOOR 

HDOR 

HEP 

HFE 

HIPO 

HIRIS 

HN1 

HM 

HOL 

HOS 

HPP 

HRIS 

I 


Gigabits Per Second 

Ground Based Support System 

Geosynchronous Earth Orbit 

Gas Election Phosphor 

Ground Forward Commands 

Government-Furnished Equipment 

Government-Furnished Property 

Government Fiscal Year 

Government/Industry Data Exchange Program 

Geometric Nath Model 

Geostationary Meteorological Satellite 

Greenwich Mean Time 

Generic Maintenance Work Station 

Guidance, Navigation, and Control 

6eneral-Purpose Computer 

General-Purpose Processor 

Global Positioning System 

Gamma Ray Observatory 

Ground Service Center 

ground Support Equipment 

(Robert H.) Goddard Space Flight Center 

Generalized Tethered Object System Simulation 

Hardware 

High-Order Algorithmic Language 

Help Desk Discrepancy Report 

High Density Digital Recording 

Heterogeneous Element Processor 

Human Factors Engineering 

Hierarchical Input Process Output 

High Resolution Imaging Spectrometer 

Habitation Module One 

Habitation Module 

High Order Language 

High Order Systems 

High Performance Processors 

High Resolution Imaging Spectrometer 

Interactive 


XVI 



I/F 

I/O 

IBM 

IC 

ICAM 
ICB 
ICO 
ICOT 
ICS 
10 
ID 
I DM 
IONS 
IEEE 
I EMU 
IF 

IFIPS 

ILO 

IMU 

INS 

IOC 

IOP 

IPCF 

I PC 

I PL 

I PR 

IPS 

IR 

IR&D 

IRN 

ISA 

ISA 

ISON 

ISO 

ITAC-0 

ITT 

IV&V 


Interface 
Input/Output 
IBM Corporation 
Intercomputer 

Integrated Computer-Aided Manufacturing 
Internal Contractor Board 
Interface Control Oocument 

Institute (for new generation) Computer Technology 
Interpretive Computer Simulation 
Interface Diagram 
Identification 

Intelligent Database Machine 
Information and Data Management System 
Institute of Electrical and Electronic Engineers 
Integrated Extravehicular Mobility Unit 
Intermediate Frequency 

International Federation of Industrial Processes Society 

Injector Laser Diode 

Inertial Measurement Unit 

Inertial Navigation System 

Initial Operating Capability 

Input/Output Processor 

Interprocess Communications Facility 

Interprocesses Communication 

Initial Program Load 

Internal Problem Report 

Instrument Pointing System 

Infrared 

Independent Research and Development 
Interface Revision Notices 
Inertial Sensor Assembly 
Instruction Set Architecture 
Integration Services Digital Network 
International Standards Organization 
Integration Trades and Analysis-Cycle 0 
International Telegraph and Telephone 
Independent Validation and Verification 


xvii 



IVA 

Intravehlcular Activity 

IWS 

Intelligent Work Station 

JPL 

Jet Propulsion Laboratory 

JSC 

(Lyndon B.) Johnson Space Center 

KAPSE 

Kernal APSE 

KEE 

Knowledge Engineering Environment 

KIPS 

Knowledge Information Processing System 

KOPS 

Thousands of Operations Per Second 

KSA 

Ku-band, Single Access 

KSC 

(John F.) Kennedy Space Center 

Kbps 

Kilobits per second 

Klpc 

Thousand Instructions per cycle 

LAN 

Local -Area Network 

LaRC 

Langley Research Center 

LCC 

Life-Cycle Cost 

LCD 

Liquid Crystal Display 

LDEF 

Long-Duration Exposure Facility 

LOR 

Large Deployable Reflector 

LEO 

Light-Emitting Diode 

LEO 

Low Earth Orbit 

LeRC 

Lewis Research Center 

LI OAR 

Laser-Instrument Distance and Range 

LIFO 

Last In First Out 

LIPS 

Logical Inferences Per Second 

LISP 

List Processor 

LIsP 

List Processor 

LLC 

Logical Link Control 

LNI 

LISP Machine Inc. 

“4 

Liquid Nitrogen 

LNA 

Low-noise Amplifier 

LOE 

Level of Effort 

LOE 

Low-earth Orbit Environments 

LOS 

Loss of Signal 

LPC 

Linear Predictive Coding 

LPS 

Launch Processing System 

LRU 

Line-Replaceable unit 

LSA 

Logistic Support Analysis 


xviii 



LSAR 

LSE 

LSI 

LTV 

LZPF 

M 

VP 

HA 

HA 

HAPSE 

Kbps 

MBPS 

MCAIR 

HCC 

HCC 

NCOS 

MCM 

MCNIU 

MDAC-HB 

MOAC-STL 

HDB 

HOC 

HOHC 

NDRL 

HFLOP 

HHz 

HIHO 

HIPS 

HIT 

HITT 

HLA 

HHI 

HHPF 

HHS 

HHS 

HHU 


Logistic Support Analysis Report 
Language Senslty Editors 
Large-scale Integration 

LTV Aerospace and Defense Company, Vought Hlsslles Advanced 

Programs Division 

Level 0 Processing Facility 

Hanual 

Microprocessor 
Multiple Access 
Managing Activity 
Minimum APSE 
Million Bits Per Second 
Million Bits Per Second 
McDonnell Aircraft Company 
Mission Control Center 

Microelectronics and Computer Technology Corp. 

Management Communications and Data System 

Military Computer Modules 

Multi-compatible Network Interface Unit 

McDonnell Douglas Astronautics Company-Huntlngton Beach 

McDonnell Douglas Astronautics Company-St. Louis 

Master Data Base 

McDonnell Douglas Corporation 

McDonnell Douglas Microelectronics Center 

McDonnell Douglas Research Laboratory 

Million Floating Point Operations 

Million Hertz 

Multiple-Input Multiple-Output 
Million (machine) Instructions Per Second 
Massachusetts Institute of Technology 
Ministry of International Trade and Industry 
Multlspectral Linear Array 
Man Machine Interface 

Microgravity and Materials Process Facility 
Module Management System 
Momentum Management System 
Mass Memory Unit 


xix 



NMU 

HNOS 

HOC 

NOI 

MOL 

NOS 

NPAC 

MPS 

MPSR 

NRMS 

NRWG 

MSFC 

MSI 

MSS 

MTA 

MTBF 

MTTR 

MTU 

NASA 

NASCOM 

NASPR 

NBO 

NBS 

NCC 

NFSO 

NGT 

NHB 

NISON 

NIU 

NL 

NLPQ 

NMI 

NMOS 

NMR 

NOS 

NS 

NSA 


Manned Maneuvering Unit 

Metal-Nitride Oxide Semiconductor 

Mission Operations Center 

Moment of Inertia 

Manned Orbiting Laboratory 

Metal Oxide Semiconductor 

Multipurpose Application Console 

Materials, Processing In Space 

Multi-purpose Support Rooms 

Mobile Remote Manipulator System 

Mission Requirements Working 6roup 

(George C.) Marshall Space Flight Center 

Medium-Scale Integration 

Multlspectral Scanner 

Man-Tended Approach 

Mean Time Between Failures 

Mean Time to Repair 

Master Timing Unit 

National Aeronautics and Space Administration 
NASA Communications Network 
NASA Procurement Regulation 
NASA Baseline 

National Bureau of Standards 
Network Control Center 
NASA FAR Supplement Directive 
NASA Ground Terminals 
NASA Handbook 

NASA Integrated System Data Network 
Network Interface Unit 
National Language 

National Language for Queuing Simulation 

NASA Management Instruction 

N-Channel Metal-Oxide Semiconductor 

N-Modular Redundant 

Network Operating System 

Nassl-Schneldermann 

National Security Administration 


XX 



NSF 

NSTS 

NTDS 

NTE 

NTRL 

NTSC 

Nd : YA6 

O&M 

O/B 

OASCB 

OCN 

OOB 

OOBMS 

OEL 

OES 

OIO 

OLTP 

ONCC 

OMV 

ONR 

ORU 

OS 

OSE 

OSI 

OSM 

OSSA 

OSTA 

OSTOS 

OTV 

P&SA 

P/L 

PA 

PAM 

PASS 

PBX 

PC 

PCA 


National Science Foundation 
National Space Transportation System 
Navy Tactical Data System 
Not To Exceed 

NASA Technology Readiness Level 
National Television Standards Committee 
Neodynlum Yttrium Aluminum Garnet (laser type) 

Operations and Maintenance 
Onboard 

Orblter Avionics Software Control Board 

Operations and Control Network, Operational Control Networks 

Operational Data Base 

Onboard Data Base Management System 

Operating Events List 

Operating Events Schedule 

Operations Instrumentation Data 

On Line Transaction Processing 

Operations Management and Control Center 

Orbital Maneuvering Vehicle 

Office of Naval Research 

Orbital Replacement Unit 

Operating System 

Orbit Support Equipment 

Open Systems Interconnect 

Orbital Service Module 

Office of Space Science and Applications 

Office of Space and Terrestrial Application 

Office of Space Tracking and Data Systems 

Orbital Transfer Vehicle 

Payload and Servicing Accommodations 

Payload 

Product Assurance 

Payload Assist Module 

Primary Avionics Shuttle Software 

Private Branch Exchange 

Personal Computer 

Physical Configuration Audit 


xxi 



PCA 

PCM 

PCR 

POP 

PDR 

PORO 

PDRSS 

PILS 

PIN 

PLA 

PLAN 

PLSS 

PMAD 

PMC 

PN 

POCC 

POP 

POPCC 

POPOCC 

PRISM 

PSA 

PSA 

PSCN 

PSL 

PTR 

QA 

R 

R&O 

R&QA 

R/M/A 

R/T 

RAO 

RAM 

RAP 

RC 

RCA 

RCS 


Program Change Authorization 

Pulse Code Modulation 

Program Change Request 

Plazma 01 splay Panel 

Preliminary Design Review 

Program Definition and Requirements Oocument 

Payload Deployment and Retrieval System Simulation 

Payload Integration Library System 

Personal Identification Number 

Programmable Logic Array 

Payload Local Area Network 

Payload Support Structure 

Power Management and Distribution 

Permanently Manned Configuration 

Pseudonoise 

Payload Operations Control Center 

Polar Orblter Platform 

Polar Orbit Platform Control Center 

POP Operations Control Center 

Prototype Inference System 

Problem Statement Analyzer 

Preliminary Safety Analysis 

Program Support Communications Network 

Problem Statement Language 

Problem Trouble Report 

Quality Assurance 

Restricted 

Research and Development 

Reliability and Quality Assurance 

Rellablllty/Malntalnablllty/Aval lability 

Real Time 

Unit of Radiation 

Random Access Memory 

Relational Associative Processor 

Ring Concentrator 

RCA Corporation 

Reaction Control System 


XXII 



ROB 

ROC 

REN 

RF 

RFC 

RFI 

RFP 

RGB 

RIO 

RID 

RISC 

RNS 

RNSE 

RNET 

RON 

ROTV 

RPNS 

RS 

RSA 

RTX 

S&E 

S/C 

S/W 

SA 

SA 

SAAX 

SAE 

SAIL 

SAIS 

SAR 

SAS 

SASE 

SATS 

SBC 

SC 

SCR 

SCR 


relational Data Base 
Regional Data Center 
Roentgen Equivalent (man) 

Radio Frequency 
Regenerative Fuel Cell 
Radio Frequency Interference 
Request for Proposal 
Red-Green-Blue 
Review Item Disposition 
Revision Item Description 
Reduced Instruction Set Computer 
Remote Nanlpulator System 
Root Nean Square Error 
Reconfiguration Network 
Read Only Nemory 

Reuseable Orbit Transfer Vehicle 
Resource Planning and Management System 
Reed-Sol omon 

Rlvest, Skamlr and Adleman (encryption method) 

Real Time Execution 

Sensor and Effector 

Spacecraft 

Software 

Single Access 

Structured Analysis 

Science and Technology Nlsslon 

Society of Automotive Engineers 

Shuttle Avionics Integration Laboratory 

Science and Applications Information System 

Synthetic Aperture Radar 

Software Approval Sheet 

Specific Application Service Elements 

Station Accommodations Test Set 

Single Board Computer 

Simulation Center 

Software Change Request 

Solar Cosmic Ray 


xxiii 



scs 

soc 

SOP 

SDR 

SOTN 

SE&I 

SEI 

SESAC 

SESR 

SESS 

SEU 

SFDU 

SI 

SIB 

SIFT 

SIMP 

SIRTF 

SLOC 

SNC 

SHT 

SNA 

SNOS 

SNR 

SOA 

SOPC 

SOS 

SOW 

SPC 

SPF 

SPF 

SPR 

SPR 

SQA 

SQAM 

SQL/DS 

SRA 

SRAM 


Standard Customer Services 

Systems Development Corporation 

Subsystem Data Processor 

System Oeslgn Review 

Space and Data Tracking Network 

Systems Engineering and Integration 

Software Engineering Institute 

Space and Earth Scientific Advisory Committee 

Sustaining Engineering System Improvement Request 

Software Engineering Standard Subcommittee 

Single Event Upset 

Standard Format Data Unit 

International System of Units 

Simulation Interface Buffer 

Software Implemented Fault Tolerance 

Single Instruction Multi-Processor 

Shuttle Infrared Telescope Facility 

Source Lines of Code 

Standards Management Committee 

Station Management 

System Network Architecture 

Silicon Nitride Oxide Semiconductor 

Signal to Noise Ratio 

State Of Art 

Shuttle Operations and Planning Complex 

Silicon On Saphlre 

Statement of Work 

Stored Payload Commands 

Software Production Facility 

Single-Point Failure 

Spacelab Problem Reports 

Software Problem Report 

Software Quality Assurance 

Software Quality Assessment and Measurement 

SEQUEL Data System 

Support Requirements Analysis 

Static Random Access Memory 


XXIV 



SRB Software Review Board 

SRC Specimen Research Centrifuge 

SREH Software Requirements Engineering Methodology 

SRI Stanford Research Institute 

SRM&QA Safety, Reliability, Maintainability, and Quality Assurance 

SRMS Shuttle Remote Manipulator System 

SRR System Requirements Review 

SS Space Station 

SSA Structural Systems Analysis 

SSA S-band Single Access 

SSCB Space Station Control Board 

SSCC Station Station Communication Center 

SSCR Support Software Change Request 

SSCS Space Station communication system 

SSCTS Space Station communications and tracking system 

SSDMS Space Station data management system 

SSDR Support Software Discrepancy Report 

SSDS Space Station data system 

SSE Software Support Environment 

SSEF Software Support Environment Facility 

SSIS Space Station Information System 

SSME Space Shuttle Main Engine 

SSO Source Selection Official 

SSOCC Space Station Operations Control System 

SSOCC Space Station Operations Control Center 

SSOL Space Station Operation Language 

SSON Spacelab Software Operational Notes 

SSOS Space Station Operating System 

SSP Space Station Program 

SSPE Space Station Program Element 

SSPO Space Station Program Office 

SSSC Space Station Standard Computer 

SSST Space Station System Trainer 

STAR Self Test and Recovery (repair) 

STARS Software Technology for Adaptable and Reliable Software 

STDN Standard Number 

STI Standard Technical Institute 


XXV 



STO 

STS 

SUSS 

SYSREM 

SI 

SubACS 

TAI 

TBD 

TBU 

TC 

TCP 

TCS 

TOASS 

TDM 

TDNA 

TORS 

TORSS 

TFEL 

THURIS 

TI 

TM 

TH 

TMDE 

THIS 

TMP 

TMR 

TMS 

TPWG 

TR 

TRAC 

TRIC 

TSC 

TSIP 

TSP 

TSS 

TT&C 

TTC 


Solar Terrestrial Observatory 

Space Transportation System 

Shuttle Upper Stage Systems 

System Requirements Engineering Methodology 

Silicon 

Submarine Advanced Combat System 
International Atomic Time 
To Be Determined 
Telemetry Buffer Unit 
Telecommand 

Transmissions Control Protocols 
Thermal Control System 

Tracking and Data Acquisition Satellite System 

Technology Development Mission 

Time-Division Multiple Access 

Tracking and Data Relay Satellite 

Tracking and Data Relay Satellite System 

Thin Film Electrolumenescent 

The Human Role In Space (study) 

Texas Instruments 
Technical Manual 
Thematic Mapper 

Test, Measurement, and Diagnostic Equipment 

Technical and Management Information System 

Triple Multi-Processor 

Triple Modular Redundancy 

Thermal Management System 

Test Planning Working Group 

Technical Requirement 

Texas Reconf Igurable Array Computer 

Transition Radiation and Ionization Calorimeter 

Trade Study Control 

Technical Study Implementation Plan 

Twisted Shielded Pair 

Tethered Satellite System 

Telemetry, Tracking, and Communications 

Telemetry Traffic Control 


XXVI 



TTR 

TWT 

U 

UCC 

UDRE 

UIL 

(JON 

UPS 

URN 

UTBUN 

UTC 

V&V 

VAFB 

VAX 

VHSIC 

VLSI 

VLSIC 

VV&T 

WAN 

UBS 

UBSP 

WDM 

UP 

URO 

US 

WSGT 

UTR 

XOFS 

YAPS 

ZOE 

ZONC 

ZnS 


Timed Token Ring 

Traveling-Wave Tube 

Non-restrlctlve 

Uniform Commercial Code 

User Oeslgn Review and Exercise 

User Interface Language 

Unique Object Names 

Uninterrupted Power Source 

Unique Record Name 

Unique Telemetry Buffer Unit Name 

Universal Coordinated Time 

Validation and Verification 

Vandenberg Air Force Base 

Virtual Address Exchange 

Very High-Speed Integrated Circuit 

Very Large-Scale Integration 

Very Large-Scale Integrated Circuit 

Validation, Verification and Testing 

Wide Area Network 

Work Breakdown Structure 

Wideband Signal Processor 

Wavelength Division Hultlplexlng 

Work Package 

Work Release Order 

Workstation 

White Sands Ground Terminal 

Western Test Range 

XEROX Distributed File System 

Yet Another Production System 

Zone Of Exclusion 

Zone Of Non-Contact 

Zinc Sulfide 


XXVII 



Volume II 

TASK 3 - TRADE STUDIES 


This volume contains trade studies for Section IX through Section XVII of the 
Trade Studies Report. Table 1 lists all trade studies by subject for both 
Volumes I and II. The reader is referred to the introductory sections of 
Volume I relating to the methodology for conducting the trade studies. 
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SOFTWARE DEVELOPMENT, 

TEST AND INTEGRATION CAPABILITY TRADE STUDY 


1.0 INTRODUCTION 

The purpose of this trade study is to compare and contrast three methods of 
providing a test and integration capability. Since more knowledge about the 
DMS will need to be known before one method can be determined to be better 
than the other, this trade study will concentrate on comparing and contrasting 
the different options under various assumptions. 

The trades study will only directly address the onboard data management system 
including core subsystems and payload applications. Associated space vehicles 
and ground systems are not directly addressed. However, one of the trade 
study criteria is to evaluate the options for expandability and flexibility so 
that they could be used for testing of future systems such as the ground 
system, free flyers, etc. 

1 . 1 BACKGROUND 


The Space Station data processing system will be large, complex and 
distributed. The test and integration capability must be able to support 
execution of a large amount of code. Because the system will be distributed 
the test facility must support concurrent processes and multiple processors 
while providing diagnostic control over all processes. It must provide this 
diagnostic control without seriously affecting the system timing and 
synchronization. The communication between the processors will involve a high 
volume of bus traffic that must be monitored and diagnosed. Finally, since 
the software for the system will be developed by multiple contractors, the 
test and integration capabilities must support a coordinated effort. 

1.2 ISSUES 

The creation of an adequate test and integration capability for a distributed 
system will be difficult and some of the reasons are: 
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1. The systems will be complex. 

2. Multiple processors must be observed (dispersed test objects). 

3. Concurrent processing must be observed. 

4. System timing and synchronization must be preserved. 

5. There will be a high volume of bus traffic (large amounts of I/O). 

6. The software integration will involve software from many different 
contractors . 

7. Test methodologies for distributed system are not well developed or mature. 

The test and integration capability may have additional problems to address 
due to some of the specific characteristics of the Space Station system. Some 
of these problems could be: 

1. Lack of sufficiently available target hardware for testing purposes. 

2. Lack of appropriate test connectors and other diagnostic equipment to be 
provided with the processor hardware. 

3. Lack of commercially available diagnostic hardware and software packages 
for use with the target hardware. 

4. Use of multiple kinds of processors. 

5. Use of multiple programming languages. 

An additional known issue specific to the Space Station system is the 
requirement to be flexible and expandable enough to support technology 
insertion and to be reusable for other future space systems. 

1.3 TRADE STUDY CRITERIA 

1.3.1 GENERIC 

1 . 3 . 1 . 1 COSTS 

DEVELOPMENT (NON- RECURRING) : These include all costs to design and build the 

first working system. 
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UNIT (RECURRING) : These include costs for providing additional working systems. 


LIFE CYCLE: These include all costs to maintain working systems, train new 

users to test software using the systems, and providing user assistance. 

1.3. 1.2 RISK 

DEVELOPMENT (TECHNOLOGY READINESS, DESIGN DIFFICULTY): There is an amount of 

risk involved in projecting what the current technology will be when the 
system is designed. 

PRODUCTION (PRODUCIBILITY, COST/SCHEDULE, ETC): There is also an amount of 

risk in projecting the state of technologies (such as high speed processors, 
etc.) that will exist when the test system is put into use. 

1 . 3 . 1 . 3 PERFORMANCE 


This criterion addresses the effectiveness of the testing system resulting 
from a given method. For example, the test system could be ineffective 
because of being finished too late for software development, insufficient 
capability, poor availability, etc. The test system would be effective if it 
finds errors, is user friendly, and is cost effective to build and operate. 

1 . 3 . 1 . 4 STANDARDIZATION/COMMONALITY 

The possibility of using common available hardware and software will be 
considered. In general providing common (and possibly commercially available) 
hardware and software building blocks for the system will reduce cost, 
training and maintenance. 

1.3. 1.5 GROWTH/TECHNOLOGY INSERTION POTENTIAL 

The flexibility of the systems resulting from each method will be considered. 
This includes the flexibility to: 
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1 . Upgrade to new target hardware 

2. Expand the capability of the test system (insert new test equipment 
technologies) 

3. Test systems other than Space Station 

J 

1.3.2 TRADE STUDY UNIQUE 

1.3. 2.1 LOANER SET POTENTIAL 

For off site testing the SSE must provide a "loaner set". This is a minimum 
test capability so that testing can be done at contractor software development 
sites. It is to be a stand-alone autonomous test facility. The cost of 
providing a "loaner set" based on a given option will be considered. 

1.3. 2. 2 DISTRIBUTED SYSTEM APPLICABILITY 

Distributed systems testing is a very immature technology so there will be an 
amount of risk with each method. Relative risks of the methods will be 
indicated during the comparison. The three levels of risk considered are: 

1. Risk of resulting in an unusable system. 

2. Risk of resulting in a poorly usable system. 

3. Risk of resulting in an unmaintainable or expensive system. 

1.4 APPLICABLE OPTION PAPERS 

o Software Development Options White Paper - SSDS A/A study task 2 
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1 . 5 ALTERNATIVES 


The three options compared are 

1. Executing the software in an emulation of the target hardware(l). 

2. Executing the software in the target hardware. 

3. Executing the software in an facility that is partly target hardware and 

partly emulated target hardware. 


1 For the remainder of this paper TARGET HARDWARE will be defined to be the 
expected Space Station Data Management processors. These are the Bus 
Interface Units, Subsystem Data Processors and any unique processors that 
might be present for specific application software. 
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2 . 0 METHODOLOGY 


Background information was obtained by studying the papers listed in the 
reference section and from experience with the following projects. 

o FSD Houston Onboard Shuttle Systems 

o FSD Manassas SUBACS Project 

o KSC Launch Processing System 

o JSC Advanced Project Simulation Interface Buffer (SIB) Study 

Next, for each option, the operational concept for the Space Station system 
was studied and compared to previous project experience using the trade study 
criteria. 

3.0 RESULTS 

3.1 BASIC SUMMARY 

The main advantages of the emulation strategy are: 

o It allows a great amount of control over the execution of the target code. 

o By not requiring the use of any special hardware, this strategy is very 

available. Since the test facility is just software, it can be used by 
many people at the same time at any location where there is a supporting 
host computer. For very low level testing such as unit testing the tests 
might be run on an intelligent workstation. 

o The technology for building an emulation test facility is known. 

The main disadvantages of the emulation strategy are: 

o It requires a significant amount of software development to build the 
emulator. This relates to a fairly high development cost. 
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o It is not flexible. If the target hardware (instruction set architecture) 
changes then so must the emulator. This relates to high maintenance costs. 

o It requires an extensive amount of cpu time per amount of simulated run 
time. If long simulations are desired then this relates to a high 
operational cost. 

o It does not provide a realistic operating environment. 

The main advantages of target hardware use are: 

o If the real hardware is available then this would be the easiest facility 
to setup. However unless special hardware and software is added to 
provide diagnostics, this is unsuitable for testing. For a distributed 
system there are some fundamental diff iculties(2) in developing add-ons to 
the target hardware to develop a usable test facility. 

o The real hardware obviously provides a more realistic test facility. 

However all the add-ons tend to decrease the realism. 

The main disadvantages of target hardware use are: 

o If the target hardware is not available until late into the 

development/integration cycle then this strategy is not viable. 

o The configured target hardware system may be very expensive to provide in 
a reasonable quantity so that it will be available to all testers. This 
relates to either a high operational cost or poor availability. 

o It will be very difficult to obtain a controlled test capability (e.g., 

diagnostics may alter the timing of software execution in target hardware). 


2 VISIBILITY INTO THE INTERNAL OPERATION OF A DISTRIBUTED PROCESSING SYSTEM 
by L. Killingbeck IRAD project 4H02 
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The main advantages of target hardware/emulation combination are 

o It provides a number of design options that may help reduce the 
development risk and cost. 

o A capability based on this option could be expanded so that problems found 
when software is operating in a target hardware processor could be 
diagnosed in by running the software in an emulator while the rest of the 
system is in target processors. 

The main disadvantages of target hardware/emulation combination are 

o It requires an amount of new technology to interface an emulating 
processor with a real hardware processor. 

o Since both hardware and emulation are used this option, it has the 
combined disadvantages of the first two options. 

3 . 2 BACKGROUND INFORMATION 

3.2.1 EMULATION 


The emulation strategy for an test and integration capability would involve no 
use of the target hardware during testing. Instead, an emulation of the target 
hardware would be used. A software program would simulate execution of 
instructions of the SDP or BIU in a host computer. This is depicted in Figure 
1. The Shuttle Primary software has had experience using a test capability 
based on an emulation approach. The onboard operating system (FCOS) was first 
tested using a capability that was called Interpretive Computer Simulation 
(ICS). The emulation portion of ICS was developed by the designers of the 
onboard computer (AP-101) to test the design of the AP-101 . It modeled the 
internal logic of the computer. This emulator was brought to Houston where 
additional diagnostic features and a user interface were added. ICS was then 
used by the developers of the operating system, who were coding in assembly 
language, to test their software. This method of testing worked very well. 

The diagnostic features provided allowed the developers to test and debug 
their software very effectively. 
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Concurrent Users: 



Figure 1. Emulation option configuration 
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There were some disadvantages to using ICS. It was very slow. The run ratio 
(amount of host cpu time per time of simulation) varied but was about 100 to 1 
(on an IBM S360/75). This was not a significant problem as long as the tests 
were only a few seconds in length which was all that was initially needed by 
the operating system developers. Another disadvantage was that no 
environmental or sensor/effector modeling was supplied. This again was not a 
significant problem to the initial operating system testing. However 
application developers need longer test run times and modeling capabilities to 
do their testing. 

Another test facility was provided for application developers. This was 
called Functional Simulator (FSIM). The application developers did their 
programming in a high level language and could compile their source code into 
the host native code for execution. Since the real operating system could not 
be supplied because it was written in AP-101 assembly language, a model of the 
operating system was supplied. This caused some difficulty because operating 
system development wa3 still going on after FSIM was developed. Thus the 
modeled operating system did not always match the real operating system. 

3.2.2 TARGET HARDWARE USAGE 

This option would involve executing the software in the actual target 
hardware. Additional special hardware devices would need to be attached to 
the target hardware to provide diagnostics. This is depicted in Figure 2. 

While ICS and FSIM were being used to do Shuttle testing, another test 
facility was being developed. This new test facility involved using an AP-101 
computer (GPC) and Input/Output Processor (I0P). The GPC was supplied with 
what was called a test connector (or AGE connector). This was used by the 
hardware developers to do hardware testing. A device called a Flight 
Equipment Interface Device (FEID) was built that interfaced both the GPC via 
its test connector and the I0P via its ports to the host computer. This 
setup allowed stop/starting of the GPC/IOP, access to their memory and general 
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I/O capability. The host ran all the simulator models that generated inputs 
for the GPC/IOP , software that interfaced the models and the FEID, and 
software that interfaced with the FEID to perform diagnostic actions. This 
setup allowed the target processors to be used for testing while allowing a 
very large amount of diagnostic and simulation capability. The run ratios for 
this setup are close to real time. 

The FEID setup is a fairly complex and expensive test facility. For the 
majority of the time that development and test were being done only three 
FEIDs were available. A facility such as this may not be practical to provide 
in a ' loaner set ' . 

There are a significant number of difficulties in using a test facility such 
as this for testing a distributed system. A distributed system would involve a 
number of processors. Stopping and starting these processors without severely 
affecting the timing and synchronization of the system would be extremely 
difficult. There is also a problem with losing I/O. When the processors are 
stopped, the data coming to it on the bus must be captured until the processor 
begins receiving again. Even then the processor must catch up on all the data 
it missed. This will be a serious problem because of the high volume of bus 
traffic anticipated in the Space Station system. 

Another problem would arise if the target processors do not have AGE test 
connectors such as the AP-101 had. There were also a number of other 
features(2) that the AP-101 provided that were taken advantage of in the 
development of the FEID. The lack of any one of these would make the 
development of this type of test capability more difficult. 

3.2.3 EMULATION AND TARGET HARDWARE USAGE 

This option involves combining the previous two options. The testing would be 
done in a configuration where some of the hardware is emulated and the rest is 
actual target hardware. Additional hardware and software may be needed to 
achieve emulation/target hardware communication. This is depicted in Figure 
3. There is no direct experience with using such a system. 
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A test capability based on this approach would involve processor emulation 
software running in the host along with the models, etc. An interface device 
would connect the host and target processor. Some of the software being 
tested would run in the emulator and the rest would run on the target 
processor. An example of this would be using a target hardware subsystem data 
processor with the BIU and other necessary processors being emulated on the 
host. When using this capability, the software that is being tested would be 
execute in the emulator. The emulator usually can provide much better 
diagnostic capability than the target hardware approach. Since the software 
running in the target processor is not the primary test software, less 
diagnostic hardware would be required for the target processor. 

One of the desired capabilities for the integration test facility(3) is the 
following. Suppose during integration testing a problem is isolated to the 
software in a particular subsystem. And to diagnose the problem requires 
more diagnostic capability than is available with the current configuration. 
The test is reconfigured so that the suspect subsystem is running with 
detailed diagnostics while the rest of the system is running as before. The 
part emulation and part target hardware approach would provide this 
capability. The suspect subsystem could be taken out of a target processor 
and run in the host emulator while the rest of the system continued to run in 
the target hardware. 

This approach would be much more flexible while combining the advantages of 
the other two options. However a capability based on this approach would be 
much more difficult to design and develop. It would require a large dedicated 
amount of host cpu to allow the emulation to run at least as fast as real time 
so that it would not be necessary to stop the target hardware. If this is not 
possible and it is necessary to stop the target hardware, then this would 
require the special hardware be used to start and stop the target hardware. 

The problems in doing this were discussed earlier. 


3 • TESTING SOFTWARE IN A TACTICAL BUS-ORIENTED DISTRIBUTED SYSTEM, 

Richard F. Rashid and Charles V. Webber, IBM IRAD Project 2M45 
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3.3 OPTIONS COMPARISONS 


The purpose of test and integration is to find errors in the interfaces/ 
communication structure between software modules of a system. When the 
modules are interfacing across multiple processes of a distributed system, 
integration testing becomes a very challenging and important task. It is 
challenging because of the difficulty in creating an adequate test 
capability. It is important because of the likelihood of having errors and 
the difficulty in locating the specific errors later in system testing. The 
likelihood of having errors in the design and code of the distributed 
functions is high because designing distributed systems is an immature 
technology (3) . 

Each option ha3 an amount of risk involved. Each would require a significant 
amount of time and resources to develop. 

The significant development item for the emulation approach would be the 
development of the software that emulates the target processor. The 
technology for doing this is known so there is little risk of failing to 
develop a usable system with this approach. There would be a very significant 
amount of manpower needed to design and code the emulator(s). However it is 
likely that an emulator can be acquired, as it was for Shuttle, from the 
hardware developers. 

3.3.1 EMULATION 

Since an emulator would not require target hardware, the cost required to 
supply additional test facilities based on this approach would be small. The 
only significant cost item is the amount of CPU required to actually run the 
emulator. 

The potential negative aspects are the following. If only enough CPU could be 
supplied to run the emulator at many times more than real time, then the test 
capability would be a poorly usable one. As hardware changed, the emulator(s) 
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would need to also be changed to correctly model the hardware. Also each new 
type of processor added to the system would require the development of another 
emulator. This, combined with the complexity of the emulators, might create a 
significant maintenance expense. There is a risk in using an emulation test 
capability in that the emulator would not correctly model the hardware and the 
software system might work correctly on the emulator but not work correctly on 
the actual hardware. 

3.3.2 TARGET HARDWARE USAGE 

There are many significant development items necessary to implement a test 
capability that had maximal use of the target processors. Several special 
hardware devices would need to be developed to provide diagnostic 
capabilities. The additional hardware would require a significant amount of 
software to allow users to run test cases using them as the Shuttle project 
FEIDs did. Each of these different devices and their associated hardware 
would involve their own amount of development cost and risk. The test 
facility as a whole would require the development of new technology. For 
example it is not currently known how to stop/start a distributed system 
without seriously affecting the timing of the system. 

There is some risk that a test facility based on this approach might not be 
able to preserve system timing and thus might not be usable at all. There is 
some risk that it might not provide enough diagnostic capability thus 
preventing the detection of serious problems until late into the integration, 
or they might not be detected at all. Thus it might be a very poorly usable 
system. The cost of supplying additional test facilities based on this 
approach would be large. For each additional test facility, target processors 
and special diagnostic hardware devices would need to be supplied. The 
diagnostic hardware would likely be expensive to provide since it is not off 
the shelf. Each development group will likely require different mixes and 
numbers of processors to do their testing. Rather than providing each 
contractor with a common test capability that would have all they would need 
and more, it may be necessary (for the sake of cost) to provide contractors 
with a customized test facility. As new types of processors are inserted into 
the system or new technology is inserted, new problems will need to be 
addressed to preserve the use of the test facility. 
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3.3.3 EMULATION AND TARGET HARDWARE USAGE 


The combined target hardware/emulation approach could be implemented at 
different levels. To provide the option to use the target hardware or an 
emulation of each type of processor would require as much development effort, 
risk, and cost as both previous options combined. An alternative level of use 
of this approach would be to first use what is available or is easily 
developed. Whatever emulators were already available would be used. An 
attempt would be made to use all easily available target hardware. If a 
problem were encountered in developing a portion of the test capability using 
target hardware, an emulator could be developed instead. 

If the host/target hardware interface technology were sufficiently advanced, 
this option would provide the least development risk because it offers more 
design options. To supply facilities of this type for contractors to use 
would cost less than the full target hardware option but more than the full 
emulation option. Since there is a significant amount of both software and 
hardware to be maintained, this option would result in a high maintenance 
cost. 

4.0 CONCLUSIONS 


In the past software testing and simulations have been done in the same test 
environment. Because of the problems in creating a distributed simulation 
capability that supports all the diagnostic capabilities needed for software 
testing, the two activities may have to be separated. 

In the lower levels of integration testing when the processing being tested is 
contained in a single computer, the testing can proceed in a conventional 
manner using either emulation or the target hardware. Once the level of 
integration reaches a point where a high volume of data is passed between 
processes operating in different computers, then conventional means using the 
actual target hardware may be inadequate for software testing. Instead there 
are several alternatives that can be used. 
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o The system to be tested can be designed so that the functions do not 

heavily share data across processors. Clean interfaces can be designed so 
that the software in each processor can be tested independently. No 
integration testing, other than simulation runs for acceptance testing, is 
necessary for these higher , levels of integration. 

o If the system must be tested using detailed diagnostics and multiple 
processors (because of the criticality of the software or because it is 
the network operating system), then there are two possibilities. First 
the testing could be done using a complete emulation approach. Second, 
the necessary diagnostic features could be built into the system being 
designed. For example, detailed error logs could be kept by the system 
and at specific time could log it to an external device for analysis. The 
actual target hardware can still be used with special purpose hardware to 
do simulations. These simulations may not support diagnostic capabilities 
necessary for detailed software testing. 

5.0 REFERENCES 


The following papers were studied (note that literature on this subject is not 
widely available). 

o VISIBILITY INTO THE INTERNAL OPERATION OF A DISTRIBUTED PROCESSING SYSTEM, 
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o TESTING SOFTWARE IN A TACTICAL BUS-ORIENTED DISTRIBUTED SYSTEM, Richard F. 
Rashid and Charles V. Webber, IBM IRAD Project 2M45 
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X. FAULT TOLERANT COMPUTING 
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FAULT TOLERANT COMPUTING TRADE STUDY 


1 . 0 INTRODUCTION 

The fault tolerance requirements of the Space Station cannot be met by the use 
of a single processing unit, because of the possibility of losing that single 
unit through component failure or physical damage. This report compares 
several redundancy techniques which can be used to tolerate faults in 
computing systems. Since selection of a particular technique depends on the 
needs of individual applications, the report is organized to show the methods 
available for an application to meet its fault tolerance criteria. 

1.1 BACKGROUND 

The Space Station will have subsystems with a wide variety of requirements for 
fault tolerance. The basic requirement in the Phase B RFP is that all 
subsystems which are safety critical (category 1) or mission critical 
(category) will be fail-operational/fail-safe/restorable (FO/FS/R); i.e., 
fully operational after one failure and operate in a safe mode after two 
failures of the subsystem with the capability to manually restore full 
operational capability. Subsystems which are not safety or mission critical 
are classified in an "other" category (category 3) and are required to be fail 
safe . 

The active redundancy implicit in FO/FS/R requires the use of multiple copies 
of the critical subsystem elements, which in turn implies penalties of power, 
volume, mass and other physical properties, all of which are limited resources 
onboard the Space Station. Therefore, less critical subsystems are expected 
to use lower levels of active redundancy resulting in, either a lower 
probability of isolating the fault to a particular unit or a lower probability 
of detecting the fault in the first place. The time needed to recover from a 
failure also varies with the particular implementation of fault tolerance, 
ranging from sub-seconds for high redundancy levels of active systems to 
minutes or hours for physical replacement of units. 
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1.2 ISSUES 


The basic issues of fault tolerance are: 

o man-tended versus manned operation 
o the number of faults which must be tolerated 

o whether these faults must be tolerated simultaneously, or whether 

repair or replacement of the fault unit is allowed between failures 
o the time to recover from a fault 
o the probability of detecting a fault 

o the probability of isolating the failed unit after a fault is detected 

o the nature of the faults to be considered (simple component failure 
versus physical destruction of the unit as a whole) 

1.3 TRADE STUDY CRITERIA 


The trade study criteria used are di'vided in two groups; generic and trade 
unique . 

1.3.1 Generic 

The generic criteria are: 

1. Cost (Development and Recurring) 

2. Risk 

3. Performance (Probability of error detection and recovery) 

4. Standardization/commonality 

5. Growth (Design extendability and technology insertion) 

6. Impacts on user, operator, and subsystem designer 

1.3.2 Trade Unique 

The trade unique criteria are: 

1. Availability/reliability of subsystems 

2. Speed of recovery 
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3. Number of spares required 

4. Ease of implementing and maintaining related software 

5. Susceptibility to unit physical damage 

1.4 APPLICABLE OPTIONS 

1.1 Data Processing Hardware (Technology Options) 

2.2.1 Fault Tolerance (Design Options) 

1 . 5 ALTERNATIVES 

The report on options for fault tolerance was organized into four sections. 
This format is continued into the summary of the trade study results in 
Section 3.0 (Reference Tables 1 to 4). These sections are: 

o Error detection 

o Hardware replication and reconf iguration 

o Damage assessment 

o Error recovery 

Both the options report and this trade study treat fault tolerance by listing 
possible methods and the characteristics of those methods. (See Table 1 thru 
4) Each subsystem may select an appropriate method from the list. In most 
cases there is no definite recommendation, as is usually required of a trade 
study. The reason is that requirements vary widely among subsystems, and 
often even within a single subsystem. It is not practical, for example, to 
recommend that every subsystem implement three active processors (for combined 
fault detection and isolation of the failed unit) just because the most 
critical applications may have such a need. Many subsystems are likely to be 
satisfied with running a single unit, possibly with another "system" processor 
monitoring basic fault status (running/stopped, power on/off, etc.). 

Therefore, Tables 1-4 have generally been arranged with the Decision Item 
column meaning "if you need . . ,", followed by a brief description of the 
option and its characteristics, and ending with the Decision Rationale column 
indicating possible applications. 


10-5 



The alternatives below are discussed in more detail in the option report and 
are not repeated in this trade study. 


Error Detection 


o Built-in test equipment (BITE) 

o Watchog timers 

o Parity and related techniques 

o Voting or external monitoring 

Hardware Replication and Reconf iquraton 

o 

Standby sparing 

o 

Reconf igurable duplexing 

o 

Pail — and-spare 

o 

l\l-modular redundancy (NMR) voting 

o 

Reconf igurable voting 

o 

Reconf igurable multicomputers 

o 

Reconf igurable multiprocessors 

Damaqe 

Assessment 

o 

Self test 

o 

Trouble reports correlation 

o 

Remote diagnostics 

Error Recovery 

o 

Check point/ roll back 

o 

Audit trail 

o 

Information validation 

o 

Recovery block 

o 

N-version programming 

o 

Backup software 

o 

Compensation 
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2.0 METHODOLOGY 


All of the techniques for fault tolerance use some form of redundancy to 
recover from errors . . Most of the techniques also use redundancy in the 
hardware or software to detect the presence of a fault. The list of 
alternatives in Section 1.5 is based on traditional methods, state-of-the-art 
systems, and research areas. The specific method to be used will depend on 
the particular needs of each subsystem. Because both volume and power are 
likely to be limited resources on the Space Station, the fundamental criterion 
may be that the smallest number of units should be selected which will satisfy 
the critical needs of the subsystem. Few subsystems on' the Space Station 
should require the very rapid detection and recovery time provided by triple 
(or higher) redundant execution of programs . Critical subsystems which have 
reasonable recovery times (seconds to minutes) are likely to select duplex 
redundancy in some form because of its rapid detection of errors, and to use 
checkpoints to recover to a known state from which to continue operations. 
Subsystems in category 3 are expected to use only a single active unit, and to 
rely on internal hardware checks and monitoring by a "system" unit processor 
for basic run/stopped status as the error detection technique, followed by 
continuation from a checkpoint. 

The general weighting of criteria in decreasing order of importance are: 

1. Criticality of the subsystem 

2. Required recovery time (the primary reason for triple redundancy) 

3. Probability of detecting a fault (the reason for dual redundancy) 

4. Probability of identifying the faulty unit 

5. Ease and risk of writing detection and recovery software 
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3 . 0 RESULTS 


3 . 1 SUMMARY 

The results of the trade study are summarized in a set of decision matrix 
tables (Tables 1 through 4) in section 3.3 for the areas of (1) error 
detection, (2) hardware replication and reconf iguraton (two tables), (3) 
damage assessment, and (4) error recovery . The areas are not completely 
independent. For example, detection of faults by cross comparison of computed 
values is only applicable to replication which executes in two or more 
processors simultaneously, while detection of errors by built-in test 
equipment (BITE) is applicable in all cases. 

3.2 RELATED TOPICS 

3.2.1 Cross Comparison of Computed Results 

The cross comparison of computed results is the basis of detecting faults in 
most of the redundant configurations. Experience has shown that this 
technique has a difficult practical problem in determining the level of 
acceptable difference in computed results before declaring a failure. If the 
design is such that results are not guaranteed to be identical, then the 
subsystem designer must somehow determine the level which both rejects widely 
differing faulty values and accepts widely differing good values. The 
appropriate level is usually found only in actual use, not during the design 
phase. A long term effort is required following the first operation, which 
can impact the life cycle cost. 

If the design guarantees identical results, there is a difficult early design 
effort to define the technique and a long term effort to assure that these 
design assumptions continue to be satisfied as changes are implemented. The 
Space Shuttle experience shows (1) that identical results can be achieved by 
redundant computers but that development of software to assure identical 
results is significantly more difficult and costly than a single machine 
design, and (2) that e very software change must be closely audited for 
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potential effects on the entire redundant system. In addition, the designer 
has the problem of assuring that inputs to all processors are identical. This 
is achieved on Space Shuttle by closely synchronized input operations, with 
special hardware that allows one computer to request inputs and the other 
computers to listen to the response. A more general method is for each 
processor to read its own sensors, then exchange its inputs with all other 
processors to select a common value. Reference 1 shows that this design 
actually requires four processors and a double exchange to assure selection of 
the same value even for tolerance of a single fault. Any subsystem which aims 
for identical results should be aware that such a design is much more 
difficult than simplex software. 

As a final observation on this topic, the mixing of different types of 
redundancy in a single processor is impractical at best. Even dual redundancy 
with tolerance checks will need to consider timing differences in setting the 
tolerances. If the loading of the processors is not the same (e.g., the 
subsystem is executing at a relatively high priority in one processor but at a 
relatively low priority in another processor), the subsystem is unlikely to be 
able to find any acceptable tolerance level. This problem has strong 
implications on the ability to combine subsystem processing as a strategy for 
total system fault tolerance. 

3.2.2 Reliability and Sparing 

Fault tolerance on Space Station has been specified as fail-operational, 
fail-safe, restorable (FO/FS/R) for critical systems. However, the 
reliability of the system is also of importance. One major contrast to Space 
Shuttle in this regard is the duration of a mission. Combined with the 
potentially larger number of required processors, the effect may be many 
expected failures between resupply cycles. The implication is either several 
onboard spares for replacement of failed units or the ability to repair such 
units on orbit (possibly by interchanging parts among the failed units). 


10-9 



Some reliability estimations show the effects of the larger number of units, 
the policy of common processors, and the longer interval of required 
operation. The Space Shuttle computers currently have a mean time between 
failures of about 5000 hours. A long misson may last 10 days (240) hours. 
Assuming that two computers must be operational at the end of mission for 
safety (one primary and one backup) and that all computers are running 
continuously, the probability of having less than two computers after 10 days 
is about 1 in 43,000. 

One possible Space Station growth configuration, for example, has 21 
processors (some embedded in work stations), with 17 potentially active and 4 
off. A total of 9 processors are required before functions are lost. If 
needed, one processor of a redundant pair may be removed and used as a 
replacement for an otherwise failed function. If the mean time between 
failures is 10,000 hours and the resupply interval is 100 days (2400 hours), 
the probabilty of having fewer than 9 processors at resupply is about 1 in 
20,000. However, there will be an average of 4 failures per flight. 

If the spare units are not available for use in any subsystem (e.g., the spare 
navigation processor is only available for navigation and cannot replace a 
failed power subsystem processor), then the probabilty of loss of a dual 
redundant plus one spare triad is about 1 in 130 per triad, which is much 
worse than the 1 in 20,000 for the entire system with shared common spares for 
the same total number of units. 

The primary message is that the requirement for FO/FS/R by itself does not 
assure a very high probability of retaining all functions. Either fewer 
processors may be used (with implications on less independence of development 
by subsystems), or several spare processors may be included in the logistics 
module at resupply time. The crew can expect to have to replace several 
processors between resupply cycles. The use of standard processors eases the 
problem of spares by allowing the option of moving (or reassigning through 
software) processors to other functions to compensate for failures. 
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3.3 DECISION MATRICES 


Tables 1, 2, 3 and 4 summarize the primary results of this study. The 

contents of the tables are described below. 

J 

o Table 1 (Error Detection) describes methods which can be used to detect 
errors/faults in individual orbital replacement units (ORUs). These 
methods will be the primary means of detecting errors in simplex systems 
and would supplement redundancy management in redundant systems. For 
systems in criticality category 3 these methods will provide the only 
means for detecting errors/faults . 

o Table 2 (Hardware Replication and Reconfiguration) presents an evaluation 
of how various levels and organizations of redundant ORUs can be used to 
archieve different levels of fault detection, fault isolation, and 
recovery times. Category 1 and 2 subsystems will have to be analyzed 
against the alternatives presented here and selections made based on 
individual subsystem requirements . 

o Table 3 (Damage Assessment) is related to isolating details related to a 
failure. In general these methods would not be of much value on orbit 
unless ORU are to be repaired there. 

o Table 4 (Error Recovery) describes the methods of recovery or restoring 
the operation of the software after a processor failure and methods of 
protecting against undetected software requirements , design or 
implementation errors . 

4.0 CONCLUSIONS, RECOMMENDATIONS AND REMAINING ISSUES 

The general conclusions are as follows: 

1. Subsystems which are safety critical (where loss could cause 

immediate loss of life or damage to the Space Station) should select 
at least triple active redundancy (three computers active), because 
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Table 1 

Decision Matrix: Fault Tolerance Trade Study — Error Detection 
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Table 2 

Decision Matrix: Fault Tolerance Trade Study — Hardware Replication and Reconfiguration 
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Table 2 (cont'd) 

Decision Matrix: Fault Tolerance Trade Study — Hardware Replication and Reconfiguration 
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Table 3 

Decision Matrix: Fault Tolerance Trade Study — Damage Assessment 
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Table 4 

Decision Matrix: Fault Tolerance Trade Study — Error Recovery 



of the abilty to detect the fault, isolate the faulty unit, and 
continue immediately with the remaining two units. There may be very 
few of these subsystems of this type on the Space Station. 

2. Subsystems which are mission critical (where loss could affect the 
overall operation if not corrected in a few seconds or minutes) 
should select a dual redundant system with the two computers cross 
comparing results. At a miscomparison, the action will depend on the 
ability to identify the failed unit. If the unit is easily 
identified (e.g., one just quit running or is indicating BITE 
detected errors while the other appears to be good), control is given 
to the good unit while the failed unit is replaced. If the failed 
unit is not obvious, the best response may be to give control to a 
spare unit, using a checkpoint restart, until the failed unit can be 
isolated offline. Some possible needs for this option are docking 
operations and management of the entire orbital constellation. 

3. Subsystems with low criticality (where loss for minutes or hours will 
not seriously affect operations) should select simplex execution. 

This option has the major advantages of minimizing power usage, and 
the practical advantage of much simpler software development and 
verification. Fault detection is primarily that provided by BITE, 
possibly augmented by a "system" process which monitors simple health 
of the unit. 

4. Recovery techniques are highly dependent on the application. The 
most useful technique is expected to be the use of periodic 
checkpoints written by the application to a mass storage device. 
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SPACE QUALIFIED COMPUTERS TRADE STUDY 


1.0 TRADE STUDY DEFINITION 
1 • 1 P urpose of Trade Study 

Space qualified data processing hardware represents a major element of the 
SSDS space segment and, therefore, has a pivotal role in supporting the 
development and growth of the Space Station, COP and POP. The specification, 
selection and procurement of this hardware must be comprehensively evaluated 
and defined to provide coherent solutions to the SSDS technical requirements 
while satisfying the prominent programmatic drivers. This trade study will 
address the key issues associated with this hardware to determine the 
preferred options and configurations. 

1 . 2 Background 

The SSDS architecture design is the process of translating the Task 1 defined 
SSDS functional and performance requirements into a specific system 
definition. It is anticipated that this definition will adopt a distributed 
processing approach since: 

• the station itself has physically distributed modules and subsystems, 

• processing loads may be too large to be efficiently supported by a 
centralized configuration, 

• network technologies with adequate data rates to support SSP 
applications are currently being defined/developed and will be 
available for IOC, 

• a distributed approach provides an inherently more damage tolerant 
configuration, 

• a modularity is provided that supports technology insertion, an 
orderly growth, and concepts of standardization/commonality. 

Preliminary concepts of the Space Station Data Management system have espoused 
a distributed (LAN) architecture and have also defined a subsystem (standard) 
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data processor (SDP) dedicated or assigned to each of the identified onboard 
subsystems and separable functions of the DMS. These SDP's would be a single 
configuration, physically identical, and qualified to the same environmental 
levels, thus providing absolute interchangeability. This approach is 
representative of the "commonality" concept intended to provide significant 
program acquisition and operational savings through reduced design, 
development, and test efforts, lower maintenance and tooling costs, fewer 
spares requirements and a narrower expertise base. On closer inspection, 
however, issues surface involving specific SDP configuration, applicability, 
environmental qualification, operability, and growth, to suggest that the 
above homogeneous concept may be less than realistic. The intent of this 
trade study package is to identify and resolve these issues. 

A fundamental issue to be initially addressed is the use of homogeneous vs 
heterogeneous hardware. The homogeneous concept, as noted earlier, utilizes 
only a common processor as noted in option 1 below. The heterogeneous 
approach provides the three additional options listed. 

• Option 1 - selection of a common processor. 

• Option 2 - selection of an instruction set architecture without 

specifying the physical implementation. 

• Option 3 - relaxation of the commonality concept to allow selection 

from a small set of general purpose and special purpose processors. 

• Option 4 - total selection freedom. 

Option 2 is an attempt to capitalize on the software development and 
maintenance benefits of the fixed istruction set without confining designers 
to specific hardware solutions. All technology upgrades are replacement 
candidates with this option. 
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Option 3 attempts to alleviate the blanket hardware solution approach of 
Option 1 by providing a set of common processors. Such a set might include an 
AI LISP machine and a "backend" data base machine in addition to the general 
purpose SDP . 

Option 4 allows total design freedom and would rely on a robust SSOS 
distributed operating system to maintain a functional and efficient system 
operation. 

At this generically high level of discussion, only programmatic arguments are 
exposed, however they are sufficient to derive an initial disposition of these 
options. In reviewing the complete set of evaluation criteria, provided in 
Section 1.4, the only parameter of consequence is that of "maintainability" 
which involves the manpower, tools, expertise, and spares requirements . 

Option 1 tends to minimize these maintenance requirements while Options 2 and 
4 clearly increase them by at least an order of magnitude. The additional 
burdens generated by Options 2 and 4 are judged to be too severe, therefore, 
these options are not considered feasible and will not be further addressed. 
Option 3 remains viable and is discussed as Trade Study No. 2. 

Regardless of the outcome of the final IOC configuration, it is anticipated 
that the growth configurations will tend to be increasingly heterogeneous 
because : 


• significant cost savings can be realized through continued use of 
technically acceptable hardware, 

• applications may tend to diverge in terms of DP requirements , 
particularly with the increasing momentum of Artificial Intelligence. 

In addressing the SDP, one of the more significant issues is the utilization 
of formal Military/DoD standards. The implication is that these standards 
provide a more stable product with broad commercial support in both hardware 
and software areas. The alternative commercial products, in contrast, are 
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perceived to be "moving targets" with less stability and decreasing long term 
support. The MIL— SID— 1750A ISA standard is currently widely supported and 
provides the benefit of direct software portability, however this architecture 
is not current and is further limited by a 16-bit format and a direct 
addressability of 1 Mword. Commercially available configurations are more 
technically attractive but may present a potential liability with respect to 
long term hardware and software support; 16-bit/32-bit format decisions are 
closely coupled to this issue since the 1750A is the only processor standard 
being currently supported. 

As indicated earlier, blanket utilization of a "common" SOP will not provide 
an optimal or even totally satisfactory solution to all applications. As 
discussed, a preferred option may include use of common special purpose 
architectures , i.e., LISP machines for artificial intelligence applications, 
or back end data base machines for data base management functions in 
conjunction with an SDP. 

Environment qualification levels are also considered to be an issue, 
particularly since the POP radiation environment is considerably more severe 
than that of the Space Station and COP. It may be more cost effective to 
utilize a different configuration for the POP with respect to radiation 
qualification levels or different components. 


Finally, the SDP is generally perceived as a stand-alone, black box unit, and 
is addressed from a commonality point at that level. The commercial market is 
moving toward general and special purpose single board computers, memories and 
peripheral controllers. There are significant architectural and operational 
implications to redirecting the commonality control point to a circuit card 
format with a corresponding backplane. 

An initial activity for this trade study has been the development of a 
preliminary and generic set of SDP performance requirements in terms of I/O 
rates, memory sizing requirements , and throughput. These requirements were 
developed from a survey of the functional requirements provided in the study 
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data base. The resulting envelope, shown in Figure 1.2—1, provided an initial 
target only for the purpose of conducting this trade study. The envelope 
provided is actually an expansion of the generated requirements to provide 
typical (100%) growth margins for memory and throughput. 

1 . 3 Issues 

The following paragraphs present the issues to be addressed in this study 
package . 

1.3.1 Trade 1 - Standard Instruction Set Architecture (ISA) vs Commercial 
ISA 

The primary benefit of establishing an instruction set architecture as the 
common element is that of software portability. The implications are 
substantial for a program of the magnitude of the Space Station because of 
replicated software modules and programs, and the potential of reusing 
software developed for other programs . Will a Military/DoD standard ISA or a 
popular commercial ISA provide the better approach? 

1-3.2 Trade 2 - Special Applications vs SDP 

The blanket solution of an SDP may satisfy a large number of applications 
provided the SDP design/performance requirements are judiciously selected to 
provide an adequate envelope. Some applications, however, may either drive 
the SDP envelope to unreasonable limits or may be significantly compromised in 
their own functional and performance requirements . In such cases, special 
purpose machines such as LISP machines, or data base machines, may provide 
more effective solutions. Does this limited heterogeneous mix of processors 
provide a better approach than the homogeneous sets? 
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Figure 1.2-1. 


1.3.3 


Trade 3 - Radiation Tolerance Qualification 


The radiation environment of the POP is relatively severe in comparison to 
that of the Space Station and COP. Since the overall cost of the high 
radiation tolerance components and the associate qualification effort is high, 
is it more effective to provide a differing radiation tolerant SDP 
configuration for the COP? 

1*3.4 Trade 4 - Fault Tolerance Configuration Control 

Clearly, fault tolerance will be a fundamental requirement for the onboard 
data processing, however concepts of its implementation are not as clear. One 
of the key issues in this area is subsystem/SDP fault tolerance, i.e., should 
the SDP include fault tolerance mechanisms to support detection, 
reconfiguration and recovery, or should the SSDS control these operations? 

1.3.5 Commonality Control Point 

The generic processor has been generally depicted as a box level element with 
commonality control applied at that level. An option of the current and 
developing technologies, however, is to provide high performance single board 
computers (SBC) that support a specific back plane. This approach would add 
significant flexibilities to the overall architecture while providing a number 
of programmatic benefits. Is it a preferred option to implement SDP/module 
commonality at a "standard" circuit card compatible with a defined backplane? 
This issue will be addressed purely in discussion form. 

1 . 4 Trade Study Criteria 

1hi3 section provides a complete dictionary of the parametric criteria used in 
this trade study. The criteria set selected for each trade-off activity is 
provided in Figure 1.4-1, Also shown in the Figure are the assigned parameter 
weights, which, as discussed in Section 2,0 Methodology, provide an assessment 
of the relative impact of each parameter to the project success. 
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Figure 1.4*1. Trade Study Criteria/Weighting 
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1 . 4.1 


Criteria Dictionary 


• Option Costs consists of both non— recurrent (development) and 
recurrent costs. 

a. Non-recurrent: includes basic development and qualification 

costs . 

b. Recurrent: includes not only the basic unit production costs 

but also: 

- requirements for special/more expensive hardware items, 

- special environmental requirements, 

- special reliability screening, 

• Development Risk - Addresses: 

a. Difficulty of implementation and, 

b. Difficulty of achieving design requirements . 

• Processor Performance - Addresses throughput, addressability, and 
accuracy as defined below: 

a. This measure has less meaning with the variability of 
instruction functionality. For this study, the throughput has 
been normalized by estimation to the Digital Avionics 
Integration System (DAIS) instruction mix. 

b. Addressability: size of directly addressable memory space. 

c. Accuracy: number of significant figures in processor floating 

point formats. 

• Reliability: 

Projected operational failure rates of options. 
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Physicals : 




a. Size, volume 

b. Weight 

c. Power dissipation 

• Environmental Tolerance: 

a. Vibration/Shock - assessment of ruggedness of option. 

b. Thermal - assessment of option stability over thermal range. 

c. Radiation - assessment of tolerance to total dose radiation and 
SEU. 

• Fault/Damage Tolerance: 

Assessment of the autonomous fault/damage tolerance. 

• Maintainability/Repairability : 

Ease of maintenance/repair with respect to manpower, tools, 
expertise, replacement parts availability, replacement parts costs 
and projected down-time. 

• Vendor Support: 

Assessment of long term hardware support by the vendor or second 
sources; addresses not only hardware (end item, module), deliveries, 
by vendor or second sources, but also any special screening and/or 
repair support. 

• Software Environment Support: 

Deals with the general vendor and after market software support for 
the option in terms of HOL's, compilers, and application software 
that can be re-used by the SSP . 
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Growth Accommodation: 




Consists of two elements, extendability, and insertability defined as 
follows: 

a. Extendability is the ability to add modules to an option to 
provide more capability/capacity. 

b. Insertability is the concept of direct (minimal impact) 
replacement of an option with an improved or technologically 
upgraded element. 

2.0 Trade Study Methodology 

For each of the trade areas, the following methodology has been applied. 

1 ) Fully characterize the options : Each option will be characterized as 

fully as possible to allow a fine grained assessment corresponding to each 
parameter of the criteria. 

2 ) Select and appropriate set of evaluation parameters : This set has 

been taken from the total set listed in Section 1.3 and is tailored for the 
specific trade activity. 

3 ) P rovide weighting factors for each evaluation parameter : A weighting 

factor has been assigned to each parameter of the criteria set based on its 
relative impact to the project success. Cost, for example, is a relatively 
high impact parameter and will be assigned a higher percentage weight. 
Development risk will also carry a higher weight since acquisition phase 
problems generally result in significant cost and/or performance penalties. 
Reliability, normally a high impact item, is less so on the Space Station 
because of the onboard maintainability and therefore carries a correspondingly 
lower weighting. 

4) Provide a numerical assessment for each option : A numerical 

assignment (0-10) will be entered in each option column, corresponding to each 
parameter of the criteria. This assignment provides a relative estimate of 
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the suitability or effectiveness of the option based strictly on that 
parameter. A "5" indicates an average assessment, a "0" indicates a total 
deficiency. Note that inverse parameters, such as risk are inversely rated, 
i.e., higher costs and risks generate lower ratings. 

j 

5) Score and rank the options : The parameter assignment times its 

weighting provides the option score for that element of criteria. The 
preferred option is generally identified by the largest criteria score sum. 
The exception is when an option has a rating of less than "2" for any 
parameter that has a weighting of more than '5'; that option is disqualified 
from consideration. 

®) P erform sensitivity analysis : An analysis will be performed to 

identify the key decision drivers. 

7) Re-Evaluate individual trade activities : Each trade study will be 

evaluated to determine whether the results are reasonable and expected, to 
resolve any perceived inconsistencies, and to eliminate potential coupling of 
dependent issues. 

3.0 TRADE STUDY DISCUSSION. AND RESULTS 

3 • 1 St andardization vs Commer cia l Ins t ruction Set Arc hi tecture s 
3.1.1 Discussion 

Given that a homogeneous processor network is to be implemented, and that a 
specific instruction set is to be implemented for the overall software 
benefits, this trade activity addresses whether that instruction set 
architecture should be a formal Military/DoD standard or a popular commercial 
unit. 

Military/DoD standards have been invoked to specify requirements to meet 
space/weapons systems needs, stabilize specific configurations thereby 
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promoting hardware interchangeability and software portability, significant 
benefits, provided that the standards are widely supported and therefore have 
a projected longevity. 

There are currently two DoD processor standards for consideration: the 

MIL-STD-1750A 16-bit Instruction Set Architecture (ISA), and the MIL-STD-1862B 
32-bit (ISA). Industry support for the 1750A specification is broad and deep 
representing significant vendor development investments in hardware and 
software. A growing number of technology implementations are in work as 
tabulated in Options paragraph 1.3.3, including VHSIC. The software 
portability provided by this standard would be of significant benefit to the 
SSP not only for the concepts of re-useable programs, but also because of the 
effective transparency of hardware growth and technology updates . 

The 18628 specification appears to be currently inactive because of a lengthy 
and complex instruction set; there are no projections for its resurrection, 
therefore it will not be considered as an option in this study. 

The commercial market in this tradeoff has been represented by the popular 
Motorola MC68000 16-bit and the MC68020 32-bit microprocessors . Note that the 
MC68000 is categorized as a 16-bit unit based on its 16-bit data paths and 
ALU's. 

The criteria parameters are discussed briefly in the following paragraphs. 

• Cost 

The relative development and recurring costs for the three option CPU's are 
established by the following: 

• Commercial vendor specification and application documentation is 
generally more comprehensive and the applications are broader. 

• The 1750A includes floating point data formats, considered to be a 
general requirement; the MC68020 must use a true co-processor, the 
MC68000 must use a co-processor but as a peripheral with attendant 
performance penalties. 
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Performance 




a) Throughput: The current 1750A performance is in the 0.6 MIP to 1 MIP 

range; the 1750A VHSIC implementation will provide a 3 MIP to 5 MIP range. 

The MC68000 performance is approximately 0.5 MIP while the MC68020 will 
execute at approximately 2 MIPS. 

b) Addressability: The 1750A is limited by specification to 1 Mbyte 

which is the probable minimum for SS onboard applications. It is anticipated, 
however, that this limit will be increased to 8 Mbytes at the next 
specification change. The MC68000 has a direct addressability of 16 Mbytes 
while the MC68020 has the full direct addressability of 4 Gbytes. If 
necessary, the 1750A and MC68000 based systems could utilize additional 
hardware, i.e., paging or segment registers, to further expand their 
addressing capability. 

c) Accuracy: Both commercial units have a double precision integer 

format, and would use a co— processor for floating point formats. The 1750A 
has a 32-bit and (extended) 48-bit floating point format, however, the 48-bit 
format has a substantial processing time penalty. 

• Environmental Tolerance 


There are no identified discriminants with respect to thermal or mechanical 
environments. The 1750A implementation in CMOS/SOS or VHSIC are expected to 
exhibit total dose radiation tolerances to better than 10 6 rads(Si) while 
the commercial units have a projected tolerance of considerably less. The 
68000 utilizes NMOS technology which has characteristically low total dose 
tolerance in the range of 1K-10K rads (Si). The 68020 utilizes bulk CMOS 
technology which has a higher tolerance potential but must be implemented with 
specific design/processing rules to achieve tolerance levels of any 

significance. Commercial vendors are not inclined to invest the required 
resources for such a low volume market. The 1750A must therefore be assessed 
as superior for this parameter. 
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• Vendor Support 


The commercial units may have an edge in the CPU hardware area, since there is 
currently second sourcing. It is anticipated though not guaranteed that VHSIC 
1750A units will also be second sourced. 

• Software Environment Support 

The 1750A must be awarded a significant edge in the area of software support 
since the momentum for its applicability is building and it is the target 
machine for much of the HOL/compiler development. Although the 68000 also has 
wide support, including Ada, the longevity of this support must be in question 
as the commercial market moves on the next evolutionary unit. 

3.1.2 Results 


As shown in Table 3.1-1, the Standard processor is the preferred option. 
Sensitivity analysis shows radiation tolerance, vendor support, software 
environment support and insertabi lity to be the significant factors. 

3 . 2 Special Purpose vs Standard Architectures 


3.2.1 Background 

Clearly, a fixed configuration, general purpose processor cannot provide an 
optimum solution for all applications but will, with judicious selection, 
support a large range of processing requirements . Some applications, however, 
may be better served by more specialized machines. Artificial intelligence 
(LISP) programs, for example, may be executed by the SDP but at a 
significantly speed penalty compared to the current "LISP" machines. 

The data base management function with its multiple user, minimal access time 
requirements , provides another example where application of the SDP may be 
marginal compared to special data base machines or "back end" hardware. These 
two areas, AI and D/Base management, will be traded against the SDP in this 
section. 
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TABLE 3.1 - 1 


TRADE STUDY TITLE: STANDARD VS COMMERCIAL ISA PROCESSORS 





3.2.2 


LISP Machine vs SDP 


3-2.2. 1 Discussion 

The branch of AI utilized on the Space Station is anticipated to be the 
Knowledge (Rule) Based Expert System. The estimated generic requirements for 
Space Station expert system applications are: 2 (IIP - 3 MIPS, floating point 

formats, 2+ Mbytes of internal memory and high speed disk capability, and a 
high speed I/O. Application of the MIL-STD-1750 class of processor, even the 
3 MIP - 5 MIP VHSIC implementation, has an apparently limited utility for this 
application even for today’s primitive applications. Special purpose LISP 
machines for such applications are currently available from Xerox, Symbolics, 
LMI, and TI, however. In addition. Symbolics is actively pursuing a flight 
qualified LISP machine and TI has a Navy contract to develop a 2-micron CMOS 
processor LISP machine that will perform 10 times faster than the current 
units. It is estimated that the current LISP designed units with their 
tailored architectures and micro-coding would out perform the 1750 by a factor 
of up to 6 to 8 times for true (high level) expert systems applications. 

The criteria selected for this trade is discussed in the following paragraphs. 

• Cost 


The cost of a ruggedized LISP machine including component reliability upgrade 
will be comparable to the ruggedized 1750A. Recurring costs should therefore 
be similar but the additional LISP development and qualification costs are 
applicable to that option. 

• Development Risk 


Development risk is a low impact issue since acceptable configurations of LISP 
units are projected to be available. 
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Performance 




Accuracy of the 1750A will be adequate for the expert systems applications, 
however its addressability, at 1 Mbyte, is marginal and may remain so even 
with the anticipated increase to 8 Mbyte at the next specification change. 

And, although the 3 MIP to 5 MIP VHSIC 1750 may appear to have sufficient 
throughput, it is estimated that the 1750 will still operate expert system 
software a minimum of 6 times slower than the corresponding LISP unit. 

• Reliability 

The commercial vs standard reliability assessment provided in the initial 
trade persists here. 

• Maintainability 

Addition of a second "common" (LISP) configuration to the SSDS will add to the 
program burden in terms of additional tooling, spares requirements , etc. 

• Physicals 

Circuit card oriented LISP machines are now becoming available, such that the 
physicals of the LISP and the near term 1750A units will be comparable; 
similarly, there will be no significant discriminant between the VHSIC 1750 
implementation and the TI 2-micron LISP unit. 

• Environmental Tolerance 

The projected attributes of the LISP units, particularly with ongoing 
development, shows no particular concern even in the area of radiation 
tolerance . 

• Vendor Support 

Here, as with the prior trade study, the commercial unit tends to be perceived 
as a moving target with potentially less than desirable long term support; 
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however, most commercial products provide upward compatibility to avoid loss 
of existing software. 


• S/M Environment Support 

With appropriate selection of the specific LISP configuration the software 
support should closely parallel that of the SDP. 

• Growth Accommodation 

There are no discriminants in this area. 

3. 2. 2. 2 Results 


As shown in Table 3.2—1, the LISP machine is the preferred option. 

Sensitivity analysis shows performance to be the key evaluation factor. 

3.2.3 SDP vs D/Base Machine 

3 . 2 . 3 . 1 Discussion 

The function of data base management is to accept, provide access to and 
maintain accurate copies of telemetry and engineering data, application 
programs, procedures and schedules within the on-board secondary (mass) data 

storage. This function includes access (authorization) control, directory 
maintenance, file management, plus the compare, merge, and sort operations for 
the generation of appropriate responses to subsystem or work- 3 tation initiated 
transactions. The data base system must have adequate data transfer rates and 
data access times to provide efficient transaction response times. 

Preliminary planning has assigned Data Base Management to an SDP, however, a 
qualified version of a commercially available data base machine or a back-end 
data base processors may provide a better solution. This section will examine 
this issue. 
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TABLE 3.2-1 


TRADE STUDY TITLE; SDP VS SPECIAL PURPOSE AI (LISP! MACHINE 




OPTION 1: SDP 

(1750A) 

OPTION 2: LISP MACHINE S OPTION 3: i 

CRITERIA 

WEIGHT 

EVALUATION 

TOTAL 
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TOTAL ! EVALUATION 
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7 
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The currently defined design characteristics for the on-board DBMS mass store 
are : 

• 256 Mbyte capacity 

• 10 Mbit/sec transfer rate 

• 40 millisecond access time 

• space qualified 

Since the non-recurrent space qualification effort for any special purpose 
hardware, and the effect of its use on maintainability, i.e. non-commonality, 
must all be offset by the resulting increased performance, then the 
performance requirements for IOC and growth are necessarily the key evaluation 
drivers . 

No query/response technical requirements have been established other than to 
state that response times should be consistent with commercial data base 
systems. Response times, however, are a function of the density and 
complexity of the requests. The commercial machines provide faster query 
service and excel within a multiuser high demand environment; a general 
purpose SDP class unit in the same environment would be intolerably slow. The 
Britton— Lee unit, as noted in the Data Processing Options paper, serves up to 
64 hosts, utilizing a 10 MIP accelerator for extremely fast brute force search 
operations. No data base scenarios have been provided for the Space Station 
detailing timelines and request types however a relatively infrequent query 
environment is anticipated at least for IOC. In this environment, special 

purpose machines are still faster but the delay will be inconsequential to the 
query source. A simple analysis indicates that a crude search operation on a 
file involving as much as lOOKbytes, could be performed in less than two 
seconds utilizing an SDP. 

It must also be noted that software may be more significant than hardware in 
the area of data base management. Sophisticated software can provide a depth 
of indexing such that the search operations can be accelerated by an order of 
magnitude . 
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3 . 2 . 3 . 2 Results 


It is concluded from this examination that special purpose hardware will not 
be required for the data base management function for IOC. The key drivers 
are : 


1) the increased development costs required to ruggedize a special purpose 
unit, and, 

2) the inconsequential query response time reduction that would result 
from the addition of the special purpose unit. 

This issue must be re-evaluated for growth phases when their query/request 
environment is better defined. 

3 . 3 Radiation Qualification Levels 

3.3.1 Background 

As indicated in Options section 3.5.1, the accumulative radiation exposure in 
the Space Station and COP low inclination, low earth orbits is minimal because 
of the natural shielding of the earth's magnetic field. The POP, in contrast, 
passes through the "unshielded" polar regions during approximately 30% of its 
orbit and thus is exposed to significantly higher radiation levels. 

Although radiation is potentially a key driver to the procurement activity, 
there is also considerable programmatic motivation to enforce 
standardization/commonality for the benefits of reduced spares requirements 
and narrower hardware expertise requirements . In this regard, the options, 
previously identified in the Procurement Activity white paper, are to: 

1) Qualify the SDP to the higher POP 10 year total dose radiation levels 
and use the resulting configuration for all SDP applications 

2) Provide a unique POP SDP configuration that alone has the required 
radiation tolerance, and, 
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3) Periodically replace the POP hardware following intervals consistent 
with its qualified tolerance. 

It is initially noted that in addition to total dose radiation tolerance, the 
single event upset (SEU) phenomenon, must be addressed for all space hardware 
to minimize potentially catastrophic latch-up effects are minimal. Option 1, 
however, involves only the total dose radiation effects and addresses the net 
effort to outfit the entire SDP fleet with components qualified to the POP 
tolerance requirements . Based on the current technology realities, this 
effort to provide CPU, memory, and I/O components that are radiation tolerant 
is significant. The component costs, and qualification costs will be very 
high, and will be recurrent involving a larger number of manufacturing lots 
because of the utilization of this "common" radiation qualified SDP for all 
applications . 

Option 2 addresses the effort of developing a differing configuration for the 
POP SDP in order to meet its radiation tolerance requirements . This option 
can be further decomposed to characterize this POP configuration as: 

2a) identical except for component qualification to the higher levels, or 
2b) different components and design 

Option 3 addresses the potential of periodic replacement of the POP hardware 
based on a demonstrated radiation tolerance level and monitoring dose rate 
during change-out intervals. 

Ihis trade was performed in two stages; first the preferred approach of 
options 2a, and 2b was determined, then this preferred option was traded 
against options 1 and 3 . 

33.2 Unique POP SDP Configuration Trade Effort 
3 . 3 . 2 . 1 Discussion 

Option 2a involves the effort of qualifying the components of '"common" SDP to 
the higher levels of the POP environment. The net gain of this option is that 
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the more expensive parts from the qualified production lots would be utilized 
only on the POP SDP's. A unique POP would therefore be generated with its own 
'spares' requirements , although it is recognized that these spares could be 
used in Station and COP applications if required. This option also includes 
the potential of selectively shielding components that cannot demonstrate the 
requisite radiation hardness. 

Option 2b encounters significant development costs and qualification costs of 
a fully unique configuration. 

The criteria for this trade are discussed briefly in the following paragraphs 

• Cost 

Option 2b imposes the cost of the unique configuration development. 

• Development Risk 

Program development risks are increased for the new development of option 2b. 
The risks of option 1 may be more than minimal, however, the capability of 
selective shielding for components that cannot meet full criteria reduces the 
overall option risk. 


• Performance 


Discriminants are identifiable only in the area of throughput which may be 
impacted in option 2b with its differing (higher radiation tolerant) 
components . 

• Reliability 

The component count of option 2b will most likely be higher which will tend to 
reduce its reliability. 
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Maintainability 


Both options require unique configurations and unique spares; however, since 
the 2a option will be physically replicate, except for possible component 
shielding, it has an edge in repairability . 

• Physicals 


Option 2b may in fact require a higher component count, with a resultant 
impact on its physicals; size, weight and power. 

• Vendor support 

In terms of the hardware support, option 2b will have a lower rating due to 
the lower production quantities which generally translates to reduced leverage 
on vendors . 

• S/M Environment Support 

No discriminants have been identified. 


• Growth Accommodation 
No discriminants identified. 

3 . 3 . 2 . 2 Results 

As shown in Figure 3.3 - 1, option 1, the radiation qualification of all parts 
is the preferred approach. Sensitivity analysis shows the significant driver 
in this evaluation to be development cost, develop risk and to a lesser 
extent, maintainability. As discussed in the criteria, although this 
preferred approach uses the same parts, a unique POP configuration results. 
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TABLE 3.3 - 1 


TRADE STUDY TITLE: UNIQUE POP SDP OPTIONS 
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3.3.3 


Radiation Environment Options 


3 . 3 . 3 . 1 Discussion 

This trade effort determined the preferred approach of the previously 
identified option 1 and option 3 listed below with the identified preferred 
approach from Section 3.3.2. 

Option 1 - Perform full radiation qualification of all SDP application. 

Option 2 - Utilize the above qualified parts only on the POP SDP 
applications, with the potential for selective component shielding. 

Option 3 - Periodically replace the POP SDP's. 

The criteria for this trade is discussed briefly in the following paragraphs . 
Note that only Cost and Maintainability are applicable. 

• Cost 

All three options require component radiation qualification. The net cost 
savings would be associated only with the reduced component costs of option 2a. 
Option 3 suffers significant recurrent costs of the periodic replacement 
activity even though possibly tempered by other servicing requirements . 

• Maintainability 

Option 2a requires a unique POP SDP configuration and is therefore less 
favorable . 

3 . 3 . 3 . 2 Results 

As shown in fable 3.3 — 2, qualification of all (fleet) components is the 
preferred option. Sensitivity analysis shows that recurring cost is the 
significant driver for this selection, 
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TA8LE 3.3-2 


TRADE STUDY TITLE: 
CRITERIA 
COST 

NON-RECURRING: 

RECURRING: 

MAINTAINABILITY 


TOTALS: 


RADIATION QUALIFICATION OPTIONS 


! OPTION 1: 8UAL ALL PARTS OPTION 2: NEW CONFIG ! OPTION 3: REPLACE 

! WEIGHT ! EVALUATION ! TOTAL ! EVALUATION i TOTAL ■' EVALUATION ! TOTAL 
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3.4 Fault Tolerance 


3.4.1 Background 

Fault Tolerance will be a fundamental attribute of the Space Station, to 
support the 'fail operational, fail safe, restorable' requirements of the RFP 
particularly in support of the "build-up" and potential man-tended scenarios 
of the Station. 

Fault tolerance techniques are generally distributed across several hardware 
levels, i.e. module, processor, and sub-system hardware levels with control of 
reconf iguration and recovery, generally residing at the level above the 
failure point. Management of sub-system fault tolerance could therefore 
reside in the SSDS Configuration Management/Operating System regardless of 
whether the SDP's are dedicated or assigned. There is a some consideration, 
however, implied by the NASA Reference Configuration, that the sub-systems 
should be fully autonomous with little reliance on the SSDS for anything other 

than data transfer and time references . This suggests that the sub- 3 ystem 
fault tolerance implementation should be totally imbedded within, and 
controlled by the sub— system. The final resolution may impact the design 
requirements of the SDP to include specific Fault Tolerance features in the 
form of replicated modules for to support failure detection, reconf iguration 
and recovery. The issue addressed in this section is whether the SDP should: 

1) include these additional features to support a more autonomous approach; or 

2) rely on the SSDS operating systems to provide the management. 

Discussion of the criteria for this trade effort is provided in the following 
paragraphs . 

• Cost 


The cost of additional features both in initial development and recurrent 
costs adds significantly to option 1. This differential is somewhat offset by 
the added complexities to the SSDS Configuration Management function, however, 
the evaluation still favors option 2. 
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Development risk 




Again, the necessity for the added SDP development scope downgrades option 1. 
• Performance 


For this trade, performance is interpreted as the period of latency between 
the failure and the restart. This evaluation favors option 1 because of the 
perceived reduced response time between fault detection and restart, 
particularly if 'pair and a spare F/T techniques' have been implemented. In 
many applications a relatively long latency may be acceptable however, because 
of commonality goals, the evaluation must align with the most stringent needs. 

• Growth 

No discriminants have been identified for either option. 

3.4.2 Results 

As shown in Table 3.4-1, option 2, control of fault tolerance by the SSDS is 
pref er red . Sensitivity analysis shows the key drivers to be recurring costs, 
and growth parameters . 

3 • 5 Imbedded vs Stand Alone SDP Op tions. 


3.5.1 Background 

As indicated in earlier discussions, there is considerable programmatic 
impetus toward standardization and commonality, however, these concepts have 
not been fully explored for the SDP with respect to potential control points. 
The SDP has generally been discussed as a complete, stand-alone unit. With 
the growing availability, and projected increases in single board processors 
with both general and special purpose architectures, it appears viable to 
consider a specific circuit card/back plane format for the SDP and expanded 
processing requirements . 
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TABLE 3.4-1 


TRADE STUDY TITLE: FAULT TOLERANCE 




3 . 5.2 


Discussion 


A stand-alone SDP represents a single box, fully tested by the vendor and 
containing the standard complement of memory and I/O capability. It 
represents, in fact, a common elemept of the commonality concept. It is also 
a fixed configuration, pre-defined to envelope the requirements of all 
assigned applications, and is, therefore, less than efficient in terms of 
technical utilization. It provides an adequate solution for the application 
requirements but may be deficient for some growth concepts. Extendability , 
for example, would be limited by the relatively few spare module positions 
generally available within the unit, and when modules are added, they must be 
added for all applications regardless of need in order to perpetuate 
commonality. Technology insertion may also be difficult to implement 
depending on the design and form of the internal modules; total SDP 
replacement may be required. 

The missing attribute of this apprach is a flexibility that could be provided 
by applying the commonality control at a lower level. The intense competition 
between commercial back-plane vendors will generate superior products and 
provide at least a de-facto, if not an institutional, (i.e. IEEE) standard. 

The growing OEM and after market support for these back planes is producing a 
broad variety of processor in both general and special purpose architectures , 
along with memory and I/O products sufficient to satisfy demanding system 
requirements. 'Standardization' of a specific back plane and card format for 
the Space Station Program applications will allow assigned or dedicated 
processing nodes to be established that can be tailored as desired. 

This approach facilitates: 


• extendability 

• technology insertion 

• maintenance and repair 


11-32 



reconfiguration for added memory or I/O requirements 




• re architecture for the implementation of unique computer approaches . 

The penalty for this flexibility are the added configuration management 
requirements to track the larger number of common elements, i.e. circuit 
cards, and the configurations of the processing nodes. 

The pay-offs for this approach are: 

• decreased operational costs primary due to reduced spares 
capitalization and reduced 'scrap' costs, and, 

• flexible, efficient processing nodes that can be tailored to specific 
applications . 


4.0 Conclusions/Open Issues 

This study effort has identified the preferred options to a number of the 
significant issues concerning the space qualified data processing hardware. 
These results indicate that the SOP should be: 

• a standard 1750ft unit with an option for at least a common AI 
processor 

• fully radiation qualified to the POP levels, and, 

• designed without special reconf igurabi lities for fault tolerance 

The use of a 'standard' back— plane and circuit card format should be 
considered to implement a lower level of commonality. 
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XII. DISTRIBUTED DATA BASE MANAGEMENT SYSTEM 
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DISTRIBUTED DATA BASE MANAGEMENT 
TRADE STUDY REPORT 


1 . 0 INTRODUCTION 


1 . 1 BACKGROUND 

A basic assumption made in this trade study has been that the Data Base 
Management Systems (DBMS's) that will be used in the Space Station Program 
(SSP) will not be designed from basic data base principles but rather will be 
vendor products (possibly modified for a specific application). This is 
necessary to realize cost effectiveness which is a generic trade criteria. The 
organization of data structures within the DBMS, sizing of storage and data 
processing are design decisions made after selecting a DBMS. All commercial 
products are targeted to a host environment consisting of a machine and 
associated mass storage devices running under some operating system. The 
distributed data base system has other elements as depicted in Figure 1.1.1. 
The host environment also contains the user interface and network interface 
running under a communication software package. The selection of a DBMS is 
coupled with the selection of all these host environment support elements. 
Although it is assummed that the DBMS trade is a commercial product selection 
process it is still necessary to understand the characteristics of DBMS's so 
weighted trade criteria can be established on the basis of data manipulation 
requirements . The data manipulation requirements are user driven. The 
characterization of user data manipulation requirements and the 
characterization of the data collection method and location(s) are the primary 
drivers in determining the desired DBMS characteristics such as: 

data structure 
distribution/partitioning 
rep li cat ion/ recovery 
interface 

presentations and reports 

The details of various vendor options can be traded to establish the best 
match to the requirements . The problem boils down to understanding the 

features of various vendor options and understanding the diverse requirements 

♦ 

of various SSP SSIS data handling entities. These SSIS entities are 
distinguishable because of unique data views and locations. Some segment(s) of 
the SSP DB exist(s) at each SSIS entity. At each of these entities there will 
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User Terminals 




Figure 1.1.1. Distributed Data Base Management Systems 
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User Terminals 








be individuals (or teams of individuals) called data base administrators 
(DBA's) with the responsibility to make the data base design decisions. These 
DBA's will have to understand the requirements of DB users and available 
vendor options to make decisions. This trade study will support the DBA's in 
these decisions. 

1.2 ISSUES 

1.2.1 DISTRIBUTION/ CONNECTIVITY 

One major decision will be to define to what extent each data base is 
reachable from various geographic and space locations. This aspect of data 
sharing will drive network design and universal naming conventions for the 
data structures (data sets or relations). The complexity of DB interfaces 
will also be driven by whether we have homogeneous DB's or heterogeneous DB's. 

1.2.2 ADMINISTRATION 

The issue here is to insure that the authority for data base management 
is established early in the program and this authority is not distributed so 
widely that DB state becomes difficult to control. The assignment of 
administrators needs to be done as DB entities are defined and clear 
partitions are established. 

There is a continuum of options here ranging over the spectrum of 
possible granularities given to the DB segments. Some common sense must be 
applied to assigning administrative authority over DB segments. 

1.2.3 REPLICATION/RECOVERY 

There is a possibility to implement a recovery scheme by augmenting a 
commercial product. This option can be considered if the survey of products 

establishes that adequate recovery is not provided or if a vendor option is 
selected because of superior capabilities other than recovery and augmentation 
is appropriate. Additional back-up by replication of the DB is an option. This 
may be accomplished by replication in the archive. 
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1.2.4 PARTITIONING 


1.2.4. 1 SPACE/GROUND 

Partitioning of data between space and ground is a major design decision. 
Data storage and large DBMS software packages in space could present a higher 
cost for computational and storage devices because they must be space 
qualified .This must be traded against the bandwidth needed for space to ground 
transfers and queries. The response time for space queries will have to be 
analyzed to determine if acceptable times are realizable. For the most part 
this seem3 possible since the majority of data exchange will be non- 
interactive (i.e., mainly large text block transfers). 

1.2.5 ANCILLARY DATA GROUPING 

The performance of an 0/B system which allows users an option to acquire 
ancillary data and append that data to experiment data will be highly 
dependent on the nature of the ancillary data blocks. This presents the 0/B 
DB designer with decisions concerning ancillary file structures and 
granularity of ancillary data access. 

A common block required by most users is the vehicle state (attitude, 
position vector, time) . Other groupings need to be established after user 
requirements are understood. These groupings should be such that the 0/B data 
network is not loaded down with data transfers containing a majority of data 
that will be discarded. 

1.2.6 ARCHIVE RESPONSIBILITY 

A major DB design decision that has impact at the program level is to 
determine where the functional responsibility for archiving data resides. The 
options are some reasonable assignment of the following data groups to the 
major data handling centers. 


CENTERS 


D AT A 

Engineering 
Ancillary 
Customer 

1.2.7 RECORDER MANAGEMENT 
The option to provide bulk recording in the space segments of the DB to 

aid in managing the telemetry link is an area for consideration and couples 
tightly with the 0/B DB design. The management of these recorders is another 
area needing consideration (DMS or C&T) . 

1.2.8 0/B DB OF SUBSYSTEM HISTORY DATA 

Another decision facing the 0/B DB design is to establish how much and 
what subsystem history data will be held 0/B for 0/B status support. This 
design decision couples with the need for 0/B autonomy and the communication 
system capability to support interactive communication with the ground 
segments of the DB. 

1.2.9 COMPATIBILITY OF DB's 

The use of heterogeneous institutional facilities is a major decision. 
Existing data base management systems are to be provided to the Space Station 
Program by the Level C centers. This means dealing with heterogeneous DBMS's 
and the operating systems that they run under. 

1.2.10 STRUCTURE 

The selection of a DB structure for each of the SSP DB's will be an 
important decision and require a complete understanding of the data 
characteristics and user intentions for data manipulation. Any data structure 
selected can be abused and result in poor performance if other factors are not 
considered. The organization of data within the constraints of the DBMS 
features can be called the DB architecture . It may turn out that this 
architecture is more important to performance than the DBMS data structure. 

The big decision that will be encountered designing the various DB's for the 


Data Handling 
Space Station Control 
PL Control 
Regional/Discipline 
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SSP (besides the selection of a DBMS) will be the characterization and desired 
organization (i ,e. architecture) of the data within each DB segment. Data can 
be broadly categorized into three groups: 

a) Sampled data( sequential numerical; sensor data) 

b) Text (alpha numeric; s/w prgms , presentations) 

c) Associable (tables with correctable data; mission data) 

This characterization will aid in determining the DBMS functions needed 
to manipulate each category of data. For Category 1 a flat file server may be 
an adequate DB manager option. Category 2 requires more DB manager services, 
mainly related to word processing. Category 3 represents data which must be 
organized into records or tables so additional information can be extracted by 
queries which result in presentations(reports) to the user. For Category 3 we 
must decide on the data storage structure (i.e. relational, hierarchical or 
network). This decision and the organization of data within that structure 
(i.e., architecture of DB) will determine the DB performance (throughput and 
response) , 

1.2.11 O/B INTERACTIVE CAPABILITIES 

This issue couples response requirements for onboard DB interaction with 
the requirement for onboard autonomy. At issue is what DB segments will be 
needed onboard because of autonomous operations and what segments will be 
needed onboard because interaction through communication links to the ground 
have unacceptable delays or the bandwidth is not available. 

1.2.12 GROWTH ACCOMMODATION 

Predicting growth in data storage is another design aspect which is 
critical. Large structures may become unmanageable requiring further 
partitioning and the data base managers must be flexible to absorb 
restructuring without impacting application software. Vertical growth (i.e. 
built-in margin) is an option and horizontal growth (i.e. expansion by adding 
capacity without impact to existing structures) is another option. The DB 
designer should factor growth into design decisions. 
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1.2.13 ARCHIVE STANDARD FORMAT DATA UNITS (SFDU's) 

The SFDU recommendations made by the CCSDS may be built into the DB 
archive capability. This is especially pertinent to the archiving of ancillary 
and scientific data. It is not clear at this time if the SFDU "labels" are 
related to catalogue names used by the DBMS to retrieve data blocks. Further 
study and decisions are required to integrate the standard formats into the DB 
management . 


1.3 TRADE STUDY CRITERIA 

1.3.1 GENERIC 

The generic study criteria are listed below: 

Cost 

Risk 

Performance 

Standard izat ion/Commonal ity 
Growth/Technology Insertion 

The specific performance criteria considered for the DB trade study are: 
Availability 

Ease of use (change, query) 

Response time (query, update) 

1.3.2 TRADE STUDY UNIQUE 

Trade criteria unique to the DB trade are: 

User interface 
Growth Management 
Security 

1 . 4 APPLICABLE OPTIONS 

Data Base Management (2.1.1) 
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1 . 5 ALTERNATIVES 


1.5.1 LARGE RELATIONAL DATA BASE PRODUCTS 

For many of the SSP DB segments a large relational DB product will be the 
answer. The alternatives for relational DB's and associated host environments 
are listed below. Each commercial product has unique characteristics which 
can be used to evaluate applicability to the various data base segments. The 
complete set of characteristics is not included for all products because of 
the volume of material but is included in the referenced option report. 
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TABLE 1.5.1 LARGE RELATIONAL DATA BASES 


SYSTEM 

VENDOR 

CPU/OS ’ s COST 

DEV HISTORY 


SQL/DS 

IBM 

CORP 

* 370/D0S/VSE 
with CICS 

* VM/CMS 

Commercial version 
of SYSTEM R 

ORACLE 

ORACLE 

CORP 

DG/Eclipse 

VAX/VMS, UNIX 

370-compatable 

/VM-CMS 

M6 8000/UNIX 

DEC PDP/RSTS, 

UNIX 

others 

Developed as a 
DB manager for 
SEQUEL (now SQL) 

INGRES 

RELATIONAL 

TECHNOLOGY 

INC 

VAX/VMS .UNIX 

M68000/UNIX 

others 

Based on the system 
developed at the 
Univ. Calif/ 
Berkeley 


BRITTON-LEE 

INC 

VAX/VMS 
Z80/CPM 
Univac 1100 
Datapoint 100 
DG Eclipse 
POP 11/UNIX 

Developed as a 
back-end database 
processor using 
a QUEL interface 

iDBP 

INTEL 

CORP 

None announced 

Developed for micro 
and office 
automation appl. 

RAPPORT 

LOGICA 

LIMITED 

25 mini ' s 
and mainframes 


NOMAD 

D&B 

COMPUTERS 

INC 

370-compatable/ 
VM/CMS 
NONSTOP II 

Originally a 
reporting system 
action processing 
system 

SMARTSTAR 

SIGNAL 

TECHNOLOGY 

INC. 

VAX 
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1.5.2 ONBOARD OPERATIONAL DATA BASE MANAGEMENT SYSTEM (ODBMS) 


An alternative that must be considered for the onboard operational DB 
segment is to use a commercial product. Some modification may be required if 
the product is not available for the processor being considered as the 
interface to the onboard mass storage. Some form of a UNIX based file service 
may be adequate for onboard storage of software programs and text files. The 
LOCUS system is a possibility and references are provided in the DBMS option 
report. Another distributed system to consider is the DOMAIN system described 
in reference 29 of the report. The assessment of options for the onboard DB 
must consider many factors: 

o communication with the ground DBMS (homogeneous/heterogeneous?) 
o performance (response, . . . ) 

o the inherent program requirement to minimize costly onboard storage 
o technical issues related to autonomy and automation such as: onboard 
diagnostics, training, operations manuals, ... 

The content of the onboard DB will be a prime driver in selecting an 
appropriate onboard DBMS. The Task 1 function list suggests that the 
following are potential segments for residence onboard: 

ONBOARD DATA BASE CONTENT 
DOCUMENT MANAGEMENT 

- MANUALS (PROCEDURES) 

- DAILY SCHEDULES 

- DIAGNOSTIC SUPPORT (SCHEMATICS) 

SOFTWARE 

CHECKPOINTS 
SUBSYSTEM TREND DATA 
REAL-TIME DATA 
BUFFERED DATA (RECORDERS) 
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Figure 1 .5.2.1 . Onboard Data Base Management System Interfaces 
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The ODBMS manages this data in support of the subsystems, PL's, 
experiments and customers as depicted in Figure 1.5. 2.1. 

Each subsystem has within its own memory space data that consists of: 

a) Sampled data (raw input data from sensors) 

b) Derived data (computed on basis of stored algorithms) 

c) Static data (algorithm constants that may change only for 
reconf igurations or mode changes) 

The first two categories correspond to subsystem trend data and real-time 

data. 


If all the subsystems were totally autonomous there would be no need to 
share this data. The subsystems are not totally autonomous but rather 
interact with onboard crew members and ground support to varying degrees. 
Subsystems also interchange data. Interchange of data between subsystems can 
be through predefined messages or through a data base. Predefined messages 
are much faster (without data base intervening) and are the preferred 
alternative for all subsystem exchanges. There are some exceptions. 
Flexibility is needed in defining telemetry and user interface data 
retrieval . If a data base is used for interchange, then some form of "data 
acquisition" must be supported to place the data in the data base. This is 
especially true in a distributed system where the subsystem data is 
distributed among many processors. The data acquisition function moves data 
segments into one data processor and manages that data. 

1.5.2. 1 DATA ACQUISITION 

One alternative is to have the Onboard Data Base Management System 
(ODBMS) control the storage and retrieval of all data generated by subsystems 
and intended to be used by user interface and telemetry. (Note: in the 

following discussion subsystem is interchangeable with PL/EXP) The control of 
this storage could be initiated by the subsystems. This is depicted in Figure 
1.5. 2. 1.1. Subsystems could initiate the storage of current and historical 
data at the time of initialization (or later as a result of a software 
reconfiguration) by sending a request for service to the ODBMS. The details 
of this service are explained in Appendix A. 
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Another alternative is for each of the subsystems to maintain a separate 
data base of parameters and accept requests for data from the user interface 
(just as the ODBMS would have done) and build the telemetry buffers directly. 
This would place more responsibility on the telemetry subsystem to do the data 
merging from multiple subsystem inputs (see Section 1.5. 2. 3 for the ODBMS 
interface to the telemetry buffer unit building service). Also, the 
workstation programs would not have a central directory to interrogate to see 
if a parameter was available (unless the directory was kept by ODBMS with a 
mapping to the subsystem owner) and therefore would have to communicate with 
all the subsystem data bases until the parameter was located. In addition, 
the service to deliver historical data or current data to the user interface 
would have to be carried in all subsystem processors along with the software 
to collect data into a data base. In effect, we would have duplicated the 
entire ODBMS in each subsystem computer and still a user would have to 
communicate with all subsystem ODBMS' s to find the data. This is a relatively 
unattractive alternative. 

In the alternative where the central ODBMS keeps the directory of all 
parameters to be shared but the subsystems own the data, requests for data 
would come to the central ODBMS and the central ODBMS could go get the data or 
alternatively direct the requestor to the data. This would be an alternative 
for user interface data where a "one-time" data exchange might occur. The 
direction to the data in subsystem memory space would be on a parameter by 
parameter basis and could consist of a message returned to the requestor with 
a subsystem ODBMS mailbox address where data can be requested. The user must 
then go get the data. The potential delays in this approach appears to make 
it unattractive. If the central ODBMS gets the data, the potential delays are 
still present because the central ODBMS must go and collect data on a 
parameter by parameter basis by communicating with subsystem ODBMS' s. 
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1 . 5 . 2 . 2 USER INTERFACE 


The ODBMS could support user interface programs which are loaded into the 
workstations. These programs could support graphics presentation and tabular 
formats defined by the user. The workstation could operate in any of three 
modes . 

One mode would be called the query mode since the data base is queried 
and data is retrieved and presented to satisfy the query. The other two modes 
would be menu and command. The menu mode supports the user by help panels 
which define all the configurations allowed at the workstation. The command 
mode presents panels which allow command and control of subsystems. These 
panels would be restricted by authorization access codes. The command panels 
could be predefined and only allow selection of predetermined configurations 
or modes and entry of parameters within predefined limits. 

The query mode interfaces to the ODBMS for delivery of data which is then 
formatted by workstation programs . The format (plots, tables, etc.) could be 
selectable by the user. 

1.5. 2. 3 COMMUNICATION SUBSYSTEM INTERFACE 

Telemetry buffer units (TBU's) could be built and their content 
identified by a function called Telemetry Traffic Control (TTC) . The TTC 
function delivers TBU's to the communication system buffer space for 
modulation and transmission through the communication link. TBU's contain 
subsystem data, telecommands, and telecommand acknowledgements. The process 
of building a TBU utilizes priority assignments and telemetry packet 
segmentation. The TBU may contain multiple telemetry packets (as defined by 
CCSDS) or a telemetry packet fragment. The TBU size will be limited to the 
communication subsystem toggle buffer size. Sending TBU's close to the buffer 
size would be essential to avoid bandwidth loss when a toggle buffer is still 
being filled and transmission of the other is complete. 
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The TTC interface to the ODBMS has several alternatives. The simpliest 
alternative would be to assume that the subsystem records collected into the 
ODB by data acquisition function are identical (rates and content) with the 
telemetry requirements to the ground data base. This alternative is depicted 
in Figure 1.5. 2. 3. 2 where the ODB supports TTC. In this case the grouping of 
data into a TBU would be by rate group and priority. A rate monotonic 
priority scheme could be assumed. (i.e., the higher the rate, the higher the 
priority) . 

The identification of the contents of periodic TBU's could be constructed 
by TTC using the UNIQUE-OBJECT-NAMES (UON's) defined by the subsystems and 
maintained by the ODBMS directory. After deciding what the contents of each 
periodic TBU will be (possibly multiple periodic subsystem records), the TTC 
would construct a message containing the UON's that would be in the periodic 
TBU's and attach a unique TBU name (UTBUN) and transmit to the ground data 
base. The ground DB would have a similar server to the ODBMS, accepting 
messages to define periodic TBU's. 

The layout of this message to the ground data base would have the 
following format. 


Figure 1.5. 2. 3.1 

UNIQUE TELEMETRY BUFFER UNIT IDENTIFICATION MESSAGE TO GROUND DB 



UTBUN 




RATE - GROUP 



UON 1 

1 

FIELD 1 


UON 2 

....... 1 

FIELD 2 


• 

1 

1 

1 

* 


32 bytes 


1 byte 



The TTC would then maintain a schedule of TBU's that must be built 
periodically and perform this function. Each time the UTBUN would be attached 
as a header before transmission of a UTBU to the ground DB. The ground data 
base would maintain a directory of UON's available for ground user interface. 
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The other alternative is to allow the telemetry parameters to be defined 
independent of the ODBMS subsystem record definitions. Within this 
alternative are several sub-alternatives. The subsystems could establish an 
interface to the TTC (much like the one between the ODBMS and subsystems) and 
communicate telemetry records directly. This would take the ODBMS out of the. 
loop completely. This alternative is depicted in Figure 1.5. 2. 3. 3. 
Alternately, a list of parameters (UOW's) and rates could be sent to TTC which 
in turn would gather the data from the ODB and build rate grouped TBU's. The 
overhead associated with this sub-alternative makes it unattractive. 

Some TBU's will contain aperiodic data. Data for these TBU's could be 
communicated directly to TTC and bypass the ODBMS. These TBU's will not be 
able to use the unique content identification approach (UTBU can only be used 
for periodic data defined with UON's). These TBU's will have to carry content 
identification as part of the TBU. The content identification could consist 
of a variable length leader defining the number of segments in the TBU and 
their locations within the TBU. [The final destination is a part of the TLM 
packet format (CCSDS)]. TLM packet fragments delivered in TBU's will have to 
be reconstructed in the ground data base before the entire TLM packet is 
forwarded to the final destination. 

1.5. 2. 4 MASS MEMORY CONFIGURATION 


There are several issues associated with the configuration of mass memory 
onboard the space station; distribution, flight build-up, redundancy and 
integration with the other DMS elements (SDP's and NIU's). 

The distribution issue addresses the physical distribution within the 
space station structure and also distribution on the PL and core networks. 
Figure 1.5. 2. 4.1 shows two alternatives for distribution on the PL and core 
networks. The first alternative has all the mass memory attached to a SDP/NIU 
node on the core network. This alternative would mean that PL/EXP interfaces 
with ODBMS would be through the network bridge. This could present a 
bottleneck. The ancillary data service would be across this interface in 
either alternative since ancillary data originates within the core network. 
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Alternative 1 




1 

I 

I 


J 


Mass Memory 
Managed In 
Core Network 




SDP/NIU 

Node 



~i 


PL/EXP 


PL/EXP Mass Memory 
Managed In PL Network 



Figure 1. 5.2.4. 1. ODBMS Alternatives (PL/Core Distribution) 
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The first alternative has the advantage of having only one ODBMS resident in 
the SDP/IMIU nodes. The second alternative has separate mass memory elements 
attached to a PL network SDP/IMIU node. The ODBMS resident in this node would 
service PL/EXP users. This eliminates some of the bridge traffic but 
potentially introduces the complexity of communication between two ODBMS' s. 

In addition, onboard complication would be introduced if these two ODBMS' s 
were not homogeneous (which would be an alternative). 

Another issue is the flight build-up of mass memory. The first flight 
delivers the transverse boom structure. It appears to be advisable to 
minimize the mass memory on the truss because of difficulty in maintenance and 
to minimize the volume of DMS on the first flight. On the other hand the 
ODBMS will have functions required from the first flight that need mass memory 
elements. These functions are: SDP and IMIU program loads, telemetry 

interface buffering for TDRSS loss and checkpoints for restart. The first 
alternative depicted in Figure 1.5. 2. 4. 2 is to have the SDP/IMIU nodes contain 
a nonvolatile memory (as well as working memory) where programs could be 
loaded and used at start-up. This non-volatile memory would also have to be 
used by ODBMS for the other functions (checkpoints and telemetry buffering) or 
else these functions would not be supported. There is an alternative to just 
support checkpoints using the SDP non-volatile memory for the first and second 
flight. The mass memory units would be added later on a flight with a 
pressurized module. One disadvantage of this alternative is that the ODBMS 
interface to memory is changed when the external mass memory becomes 
available. Also the ODBMS needs to run redundantly otherwise loss of an SDP 
would mean loss of the ODB . Communication between ODBMS' s in SDP's would be 
needed to maintain multiple copies of the ODB. 

The second alternative is to have mass memory units delivered on the 
first flight. If these are highly reliable units, this is also a viable 
alternative. The possibility of adding redundancy at a later flight is 
another alternative. A ground uplink to the SDP/IMIU nodes can be used to 
augment the reduced onboard redundancy . 
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Alternative 1 



Local SDP/NIU Non-Volatile 
Memory For First Flights 
(Recovery of Non-Volatile 
Memory By Transfer From 
Redundant Elements or 
Ground) 


Added on Later 
Flight in Pressurized 
Module 


Alternative 2 



Figure I.5.2.4.2. ODBMS Alternatives (Flight Build-Up) 


Mass Memory 
Available From 
Flight 1 
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The redundancy and integration of mass memory with the other DMS elements 
couples tightly with the flight build-up issue. The first alternative 
depicted in Figure 1.5. 2. 4. 3 is to have the mass memory units separate from 
the SDP/NIU nodes and have communication to the mu's on a Standard Serial 
local bus (the same bus used for subsystem sensors and effector 
communication). The ODBMS would be resident in the local SDP/NIU node 
controlling the MMU's, The redundancy in this alternative would be three 
MMU's attached to a SDP/NIU triad. Any of the SDP/NIU 's in the triad could be 
in communication with any of the MMU's (i.e., multiple ports to MMU's). Since 
local buses are used to communicate to the MMU's, the SDP/NIU 's and MMU's will 
have to be co-located . This would mean that this alternative is coupled with 
delivering all the MMU's on the first flight (transverse boom) or on flight 3 
(habitat module). A build-up in redundancy would not be possible without 
running local buses from the truss to a pressurized module (which is 
undesireable) . Alternative two is the same as alternative one except a 
parallel bus is used for NIU to MMU interface. This addes a special port to 
the backend of the NIU. This alternative would be a fall back for alternative 
one if the data rates on a serial bus were determined to be inadequate. The 
disadvantage is the addition of a third port to the NIU backend. The NIU 
backend already must support serial local buses and the SDP interface. 

The third alternative is to have an integrated SDP/NIU/MM node. (See 
Figure 1.5. 2. 4. 3) In this alternative the communication between mass memory 
and the computing elements is on an internal bus. The disadvantage of this 
alternative is the creation of a non-standard node. The advantage is the 
potential for a more manageable and higher rate communication to the mass 
memory. Another advantage would be the flexibility for redundancy build-up. 
One of these special SDP/NIU/MM nodes could be delivered on the first flight 
and uplink used as a fall back. The redundancy could be upgraded by 
delivering two additional nodes in habitat module one. 
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Alternative 1 


ODBMS (Primary) ODBMS (Backup) ODBMS (Backup) 



Standard SDP/NIU Used 
With Standard Serial 
Local Bus Interface 


Local Serial Bus 



mmu 2 mmu 3 


Alternative 2 


Same as Alternative 1 But With Parallel Interface Between NIU and MMU. 


Alternative 3 



Figure I.S.2.4,3. ODBMS Alternatives (Mass Memory Integration) 
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1.5.3 SPACE/GROUND PARTITION I IMG 


The alternatives for each DB entity is to have the DB fully partitioned 
(that is each of the OB segments resides at exactly one location) or fully 
replicated (that is each segment of the DB resides at all locations) or 
something in between. The problem with full replication is that updates must 
be exchanged to keep the copies consistent. Also, network delays can mean 
slow response. Partitioning the DB can result in improved performance by 
allowing a local computer to just handle local transactions (if the queries 
concern the local partition, otherwise, the other partitions must be acquired 
from the owner) . 

The alternatives that must be considered for space/ground partitioning is 
to replicate partitions of the data base in space when queries in that 
partition occur or have the queries relayed to the ground DB and responses 
returned to space. The same alternatives exist for ground query of space 
partitions. Partitions of the DB originating and being updated on a periodic 
basis could be kept in space and relayed to the ground for queries. 
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2 . 0 METHODOLOGY 


The approach taken in this trade study is to consider all SSIS DB 
entities and then to concentrate on the characteristics of the SSDS DB 
embedded within the SSIS, in particular the Space Station Operational Data 
Base (ODB) and the interface to the ground data base. For the entire data base 
problem this approach translates into the following stages: 

1. Define all the SSIS DB entities using the TASK 1 functions list and 
the basic premise that partitioning will be along established NASA 
institutional boundaries. 

2. Determine which of these DB's are within the SSDS (exclude IMIS 
segments) while still considering required connectivity and 
interfaces of all segments. 

3. Characterize the SSDS DB entities by: 

a) data content(type and source) 

b) functional manipulation requirements 

c) connectivity required 

4. Define alternatives for commercial products applicable to the ground 
segments . 

5. Define alternatives (commercial, modified commercial or "roll your 
own") for space segments. 

6. Partition the SSDS DB's by space/ground segments 

7. Partition the SSDS DB ground segments to as low a level as required 
to seperate by utilization (development, operational , scientific/PL) 
and also by interest domains, data types and DBMS functional 
requirements . 
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8. Trade alternatives and define recommended SSDS DB architecture 
including for each DB segment: 
data structure 

distribution/partitioning within segment 

replication/recovery 

interface 

presentations and reports 
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3.0 RESULTS 


It is not the intention of this trade study to recommend a data base 
(i.e., a commercial product) for each of the ground segments but rather to 
suggest a reasonable segmentation of DB's and reasonable commercial 
architectures for each segment. The selection will be done by the data base 
administrators and management based on further evaluation of alternatives. It 
is the intent of the trade study to analyze alternatives for the onboard data 
segment and connection to the Space Station Control Center (SSCC) data bases 
and Payload Operations Control Centers (POCC). 

3.1 DATA BASE SEGMENTATION 

Within the SSP all data bases can be separated into TMIS DB's and other 
DB's. This separation allows the TMIS to be considered part of the SSIS but 
not the SSDS. This trade study is principally concerned with the SSDS DB's. 

The data base maintained by the TMIS corresponds to section 7.5 of the 
functions list, that is "Configuration Management". The TMIS is considered to 
contain the following data segments: 

TABLE 3.1.1 TMIS DATA CONTENT 


DATA BASE 


DATA BASE CONTENT 


LEVEL B SE&I 
MASTER DATA BASE 
(MDB) 


- LEVEL A SPEC 

- SSIS CONFTG(CONNECTIVITY , ICD ‘ 

- REF CONFIG (DRAWINGS, TEXT) 

- WP ICD 1 s 


LEVEL B SE&I 
ENG MASTER SCH 
(EMS) 


- SE&I SCHEDULES 

- S/W SCHEDULES 

- HARDWARE SCHEDULES 


LEVEL C SE&I DB 


- HARDWARE SPEC's 

- SUBSYSTEM ICD's 

- S/W REQUIREMENTS 

- SSE REQUIREMENTS 


s) 
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The need for data bases other than TMIS is clear from the Task 1 
requirements in Appendix A of the DBMS options report. The segmentation of 
DB's other than TMIS is along established NASA institutional boundaries. 

TABLE 3.1.2 DATA BASES OTHER THAN TMIS 


DATA BASE 

1 

L 

DATA BASE CONTENT 

SSE DB 

1 

1 

1 

1 

L 

- SOFTWARE 

- MODELS 

- TEST SCRIPTS 

- RESOURCE SCHEDULING 

TRAINING DB 

1 

1 

1 

- PROCEDURES 

- SCHEDULES 

INTEGRATION 

1 

SITE | 

- SOFTWARE 

DB 

1 

1 

1 

- INTEGRATION SCHEDULES 

- PROCEDURES 

- TEST SCRIPTS 

SSCC DB 

1 

1 

1 

_ 1 

- SPACE STATION STATUS 

- MISSION SEQUENCING 

- COMMAND PROCEDURES 

POCC DB 

1 

1 

.... 1 

- PLATFORM/PL ENGINEERING DATA 

- EXPERIMENT DATA 

RDC/DDC DB 

1 

1 

1 

- SS ANCILLARY DATA ARCHIVE 

- PLAT ANCILLARY DATA ARCHIVE 

- FF ANCILLARY DATA ARCHIVE 

1 

SS OPERATIONAL | 

- MANUALS (PROCEDURES) 

DB 

1 

1 

1 

1 

1 

1 

1 

. 1 

- DAILY SCHEDULES 

- DIAGNOSTIC SUPPORT 

- SOFTWARE 

- CHECKPOINTS 

- SUBSYSTEM TREND DATA 

- REAL-TIME DATA 

- BUFFERED DATA (RECORDERS) 

COP/POP 

I 

1 

- ENGINEERING DATA 

OPERATIONAL 

DB | 

- SCIENTIFIC DATA 

DHC DB 

1 

1 

1 

1 

- LEVEL 0 DATA 

- SHORT TERM ARCHIVE 

- LONG TERM ARCHIVE 
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The entities identified and associated connectivity are listed in the 
following Table 3.1.3 and shown in Figure 3.1.1. 

TABLE 3.1.3 : DATA BASE ENTITIES AND CONNECTIVITY 



| H | L | 

LVL | CON | S | S | P | 

R 

|D|I|T|S|C|P|D| 


| D | V | 

C | TRACTOR j S | S 1 0 1 

D 

|D|N|R|S|0|0|H| 


MU 

1 

| E 1 C 1 C 1 

C 

| C | T | N | j P j P | C | 


| T | | 

J G M L| 1 2 

3 4 | |C|C| 


1 1 E|I | 1111 


| R | Bf 

S S S E| 

Mil 


1 I G | N | | | | j 


j S | | 

C F F W| 

Mil 


| | |G| | | II 


1 1 1 
1 

C C I| 

II II 


II 1 1 1 1 II 

NASA HDQTRS 

1 1 x 1 

1 1 1 1 1 

Mill 


1 1 1 1 II II 

LEVEL B JSC 

| X 1 1 

X 1 X 1 X 1 X 1 1 

1 II II 


1 1 1 1 1 II 1 

LVL C JSC 

i i x i 

i i i ixj 

Mill 


1 1 1 II 1 II 

LVL C GSFC 

i ixj 

|| 1 1 |x 

1 II II 


II 1 1 1 1 II 

LVL C MSFC 

1 1 x | 

1 1 1 1 1 

X 1 1 II 1 


II 1 1 1 1 II 

LVL C LEWIS 

i i x i 

1 1 1 1 1 

1 x 1 I 1 | 


II 1 1 1 1 II 

CONTRACTOR 1 

1 1 1 

X 1 1 1 1 1 

i ixj i i 


II 1 1 1 1 II 

CONTRACTOR 2 

1 1 1 

i x i i i i 

i i x | j | 


II II li II 

CONTRACTOR 3 

1 1 1 

i i x i i i 

1 1 x | j j 


II 1 1 1 1 II 

CONTRACTOR 4 

1 1 1 

j 1 1 X 1 1 

1 | x i | | 


II 1 1 1 1 II 

SSE 

1 1 1 

| 1 1 j X 1 X 

X 1 X 1 1 X 1 1 


1 1 x 1 X 1 | | II 

SSCC 

1 1 1 

1 1 1 1 1 

1 1 x 1 1 X 1 


i i i ixj j i x i 

POCC 

1 1 1 

1 1 1 1 1 

i i ixj j 

X 

| X 1 1 1 X 1 1 X 1 X 1 

RDC 

1 1 1 

1 1 1 1 1 

1 1 1 1 X 1 


| 1 1 1 j 1 1 X 1 

DDC 

1 1 1 

II 1 1 1 

1 1 1 1 x 1 


1 1 1 1 1 1 1 x j 

INTEG SITE 

1 1 1 

1 1 1 1 1 

| 1 X 1 j j 


i i i i i i ixi 

TRAINING 

1 1 1 

1 II 1 1 

i ixj i i 


1 1 1 1 1 1 | X I 

SPACE STN 

1 1 1 

II 1 1 1 

1 1 1 x 1 X 1 


i i i i ixj i x i 

COP 

1 1 1 

II 1 1 1 

Mill 


i i i jxj i i x i 

POP 

1 1 1 

II 1 1 1 

| 1 1 1 X 1 


i i ji i ii x i 

DHC 

1 1 1 
i 

II 1 1 1 

1 1 I x 1 X 1 

X 

jxj j | X 1 X 1 X 1 1 
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Figure 3.1.1. SSIS Recommended Data Base Distribution 
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TABLE 3.2.1 DATA BASE SPACE/GROUND DISTRIBUTIOIM 



- PRIMARY OWNER 


1 



- SHARED REPLICATION COPY 

| DISTRIBUTION/ 


- OPERATIONAL DATA HISTORICAL ARCHIVE 

| REPLICATION 
1 


DATA BASE 

1 

| DATA BASE CONTENT 

1 

1 

| SPACE 
1 

GROUND 


SSE DB 

1 

| - SOFTWARE 

1 

1 

P 



| - MODELS 

1 

P 



| - TEST SCRIPTS 

1 

P 



| - RESOURCE SCHEDULING 

1 

1 

1 

P 


TRAINING DB 

1 

| - PROCEDURES 

1 

1 s 

P 



| - SCHEDULES 

1 

1 

1 

P 


INTEGRATION SITE DB 

1 

| - SOFTWARE 

1 

1 

P 



1 - INTEGRATION SCHEDULES 

1 

P 



| - PROCEDURES 

1 

P 



1 - TEST SCRIPTS 

.1 

1 

1 

P 


SSCC DB 

1 

| - SPACE STATION STATUS 

1 

1 s 

P 



1 - MISSION SEQUENCING 

1 s 

P 



| - COMMAND PROCEDURES 

J 

1 

P 


POCC DB 

1 1 1 

| - PLATFORM/PL ENGINEERING DATA | | 

P 



| - EXPERIMENT DATA 

1 

1 

1 

P 


RDC/DDC DB 

1 

| - SS ANCILLARY DATA ARCHIVE 

1 

1 




| - PLAT ANCILLARY DATA ARCHIVE 

1 




j - FF ANCILLARY DATA ARCHIVE 
1 

1 

1 



SS OPERATIONAL DB 

1 

| - MANUALS (PROCEDURES) 

1 

1 s 

P 



j - DAILY SCHEDULES 

1 p 

s 



| - DIAGNOSTIC SUPPORT 

1 S 

p 



j - SOFTWARE 

1 s 

p 



| - CHECKPOINTS 

1 p 

— 



| - SUBSYSTEM TREND DATA 

1 p 

# 



| - REAL-TIME DATA 

1 p 

* 



| - BEFFERED DATA 

1 p 

1 

* 


1 

COP/POP OPERATIONAL DB | - ENGINEERING DATA 

1 

1 p 

# 



| - SCIENTIFIC DATA 

1 

1 p 

1 

# 


DHC DB 

1 

| - LEVEL 0 DATA 

1 

1 

p 



| - SHORT TERM ARCHIVE 

1 

p 



| - LONG TERM ARCHIVE 

1 

1 

_J 1 

p 
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TABLE 3.2.2 SPACE STATION OPERATIONAL DB 


P - PRIMARY OWNER 

S - SHARED REPLICATION COPY | 

* - OPERATIONAL DATA HISTORICAL ARCHIVE 


DISTRIBUTION 


PARTITION | 

1 

PLACE OF ORIGIN 

1 1 

| SPACE | 

1 1 

GROUND 

1 

MANUALS (PROCEDURES) | 

GROUND 

1 1 

1 s | 
1 1 

P 

DAILY SCHEDULES f 

SPACE 

1 1 

1 P 1 

1 1 

S 

DIAGNOSTIC SUPPORT | 

GROUND 

1 1 

1 S 1 

i i 

P 

SOFTWARE | 

GROUND 

1 1 

1 s** | 

i i 

P 

CHECKPOINTS | 

SPACE 

1 1 

1 P |l 

i i 

MOT NEEDED 

SUBSYSTEM TREND DATA J 

SPACE 

1 1 

1 P 1 

i i 

★ 

REAL-TIME DATA | 

SPACE 

1 1 

1 P 1 

i i 

* 

BUFFERED DATA j 

SPACE 

1 1 

i p i 

1 L 

* 


** NOTE 1 : THE LATEST VERSION OF SOFTWARE IS ALWAYS RESIDENT IN THE SPACE ODB 
(I.E., A REQUEST FOR AN OVERLAY DOES NOT TRIGGER A TRANSFER FROM 
GROUND TO SPACE; OLD VERSIONS ARE AUTOMATICALLY REPLACED UPON 
RELEASE OF A NEW VERSION, AUTOMATIC REPLACEMENT IF ACTIVE IN AN SOP) 


3.2 SPACE/GROUND PARTITIONING 

In Table 3.2.1, the SSDS data bases are listed and a distribution between 
space and ground Is suggested. Some elements of the data bases are shared 
between ground and onboard (e.g., training procedures. Space Station 
status, ...). What Is suggested here Is that some segments of the DB's could 
be replicated In space (l.e., the current version could be copied on request 
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and held in the space ODB partition). That is the ability to retrieve DB 
files (mainly from the ground) could be provided and these files would be held 
in the space ODB until another more recent copy was retrieved for a new 
session. The space in the ODB for the copy would be released as the session 
is closed. 

The selection of the partitions of the DB which could use this method of 
controlled replication were determined along the following lines of reasoning. 

There are two major types of data that are maintained in the operational 
data base: "realtime data" which is being updated periodically at a high 

frequency (e.g., sample subsystem data) and static data which is updated very 
seldom (e.g., software, diagnostic aids, etc.). The realtime data originates 
in space and some amount must be held there for user interface and subsystem 
support. There is no need for controlled replication in this case since the 
sampled data must be delivered to a ground data base for ground support and 
archiving. In Table 3.3.2, we see that the sampled data partitions are 
delivered to an archive and do not use the controlled replication method. The 
other partitions fall into the "static data" category and can use controlled 
replication for sharing. 

The alternative to shared replication is data query by transmission from 
space to ground and response to the user terminal. In Figure 3,2.1, the 
capabilities for return and forward links messages are presented. These 
channel capacities are shared with other communication requirements (voice, 
video, subsystem periodic data, etc. and therefore all this bandwidth is not 
available for block transfers). In the shared replication alternative, a 
block of data is transmitted on the communication links and then no further 
traffic is on the communication link. Interactions occur between the 
transferred block and the local terminals. In the remote query alternative, 
every query results in communication link transmission. It appears that the 
communication link capacities support the selection of block transfers (for 
shared replication). There would be an initial delay while the data block is 
transfered, but then the delays would be minimized since the local ODB would 
service querys. The partitions of the ODB recommended for sharing replication 
are all "text" type data (e.g., diagnostic procedures, etc.) and therefore, by 
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the nature of the functions being performed the initial delay appears to be 
acceptable. If it is determined at a later time that the block sizes are to 
large for this alternative, some feature in the ODB could be considered which 
selects between the block transfer and the remote query. This would be a 
transparent selection process. 


12-37 



Space 

Queries 
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Figure 3.2.1. Operational OB Ground/Space Partitioning 
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3.3 SSP DB SEGMENT CHARACTERIZATION 

The requirements for data base services at each entity is shown in the 
following table. The characterization of requirements was extracted from 
reference material in Appendix B of the SSDS A/A option report. 

TABLE 3.3.1 : DATA BASE MGMT SERVICE REQUIREMENTS 


NASA HDQTRS 

LEVEL B JSC 

LVL C JSC 

LVL C GSFC 

LVL C MSFC 

LVL C LEWIS 

CONTRACTOR 1 

CONTRACTOR 2 

CONTRACTOR 3 

CONTRACTOR 4 

SSE 

SSCC 

POCC 

RDC 

DDC 

INTEG SITE 

TRAINING 

SPACE STN 

COP 

POP 

DHC 


FILE SERVER 


|C| 

|R 
|E| 
I A 
I T | 
IE 


X 

X 

X 

X 

X 

x 

X 

x 

X 

X 

X 

x 

X 

x 

XI 
X 
X 
X 

x| 

X 

x 


D I U 
E1P 


REPORTS 


INTERFACE 

LANGUAGE 


S 

T 

A 

T 

I 

S| 

T| 

I| 

C 

A 

L 

F 

C 

N 

"x 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 


|X| 
|X| 
|X| 
I X | 
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4.0 CONCLUSIONS , RECOMMENDATIONS AND REMAINING ISSUES 


It is recommended that the control of all SSDS data bases (content, 
structure, connectivity, etc) be administered by NASA Level B. Local 
administrators would be accountable to a DB coordinating authority. The . 
recommendations for subdivision of SSDS data bases and their connectivity is 
presented in Table 3.1.3 and Figure 3.1.1. It is recommended that the 
contractors TMIS DB be connected to the JSC Level B DB (containing the NASA 
partition of TMIS; namely the MDB and EMS) and to the Level C center 
(containing specifications and ICD's). Other connectivity to support data 
exchange is presented in Figure 3.1.1. 

The recommendations for space/ground partitioning are given in Table 
3.2.1. Basically the originating source of data contains the primary data 
base with controlled replication at remote sites. It is recommended that a 
limited history of engineering data (i.e., sampled subsystem data) originating 
in a Space Station be held there for trend analysis and user interface. The 
realtime data should be delivered directly to a ground data base in the 
Control Center for archive. Engineering data from other unmanned space 
elements should be delivered directly to the Ground Control Center for 
archive. All ancillary data should be archived at the Control Centers, 
Regional Data Centers (RDC) and Discipline Data Centers (DDC) . Space Station 
ancillary data should be delivered from the SSCC to the POCC's. Experimental 
data should be archived at the RDC/DDC. 

The recommendations for SSDS data base characteristics are presented in 
Table 4.1. Within each data base the general content is presented and a data 
structure recommended. In some cases several structures are recommended since 
the DB contains partitions with different data applications. An example is 
the SSE data base where the software is in hierarchical data sets but the 
configuration management is relational. 
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All the data base entities are recommended to be centralized with the 
capability to share data by transmitting copies of DB partitioning to remote 
sites during query sessions. The star of each query session would result in a 
fresh snapshot of the DB partition being transmitted so intervening updates 
are be incorporated . This recommendation is made with the caviot that if the 
partitions blocks turn out to be too large, then the alternative for remote 
query be kept in reserve. 

At each centralized site it is recommended that multiple replications be 
maintained for system and media failures. The depth of replication should be 
determined by criticality and established by the DBA. 

It is recommended that the user interface to all data bases through 
directory query. The directory for ancillary data and experimental data 
should be in Standard Format Data Units (SFDU). The ability to perform ad hoc 
query on sampled data records should be supported. All DB's should support 
help panels, directory panels and standard report formats. Graphics 
presentation should be available in the SSCC ODB and Space Station ODB. 

4.1 SPACE STATION OPERATIONAL DATA BASE 


The content of the Operational Data Base (ODB) is presented in Table 
3.2.2 along with the distribution between space and ground of each major 
partition. Current estimates of the onboard ODB are as follows: 


The DMS must provide storage for 256 Mbytes on on-volatile memory. 


90 Mbytes 
10 Mbytes 
10 Mbytes 
10 Mbytes 
10 Mbytes 
50 Mbytes 
76 Mbytes 


application program loads 

checkpoints 

engineering data 

procedures 

schedules 

telemetry data acquisition 
growth margin 
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It Is recommended that the onboard operational data base have the 
structure suggested In Figure 1.5. 2.1. This alternative Is Alternative 1 In 
Figure 1.5. 2. 4.1. A separate OOBMS service would exist In the Core Local Area 
Network (CLAN) and the Payload Local Area Network (PLAN). These ODBMS's would 
be homogeneous and communicate to support ancillary data distribution, and 
other standard core services. 

It Is recommended that the alternative presented In Figure 1.5. 2. 3. 2 be 
used for the data acquisition Interface to the ODBMS. The subsystems would 
collect data Into records and deliver these records to the ODBMS on a 
dynamically negotiated basis. (More details In Section 1.5. 2.1 and 
Appendix A) The ODB would support Telemetry Traffic Control (TTC) In building 
Telemetry Buffer Units (TBU's) for deliver to the communication toggle 
buffers. The same Interface Is recommended for PL/EXP except the PL/EXP would 
deliver data In CCSDS telemetry packet format. The TTC would segment these 
packets (If necessary) when building the TBU's. 

For the build-up of the onboard mass memory configuration It Is 
recommended that Alternative 1 presented In Figure 1.5. 2. 4. 2 be used. In this 
configuration the SDP/NIU nodes manage local non-volatile memory for the first 
two flights and then mass storage units are delivered In the first pressurized 
module (HM1). 

The recommended mass memory Integration with other DMS elements Is 
presented as Alternative 1 In Figure 1.5. 2. 4. 3. In this configuration the 
mass storage Is on a local bus (serial or parallel to be determined) on the 
backend of an NIU. 

4.2 REMAINING ISSUES 

All of the Issues mentioned In Section 1.2 still remain open to some degree 
and the following Issues also need to be considered. The matter of 
Integrating text and graphics In DB partitions which contain presentations and 
reports needs to be addressed. 

The compatibility of ground DB segments needs to be considered In light 
of the recommended OB connectivity. 
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The concept of a switchable interface to mass store for the buffering of 
data and then merge in the communication subsystem (as shown in Figure 4.2.1) 
needs to be evaluated. This is the proposed interface to the communication 
node to get buffered data merged with realtime data. 
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APPENDIX A 

DATA ACQUISITION CONCEPT 


This Appendix expands on the data acquisition service concept. 

Subsystems could. Initiate the storage of current and historical data by 
sending a request for service to the ODBMS. The service request could be to a 
standard mall box (with multiple sockets to service concurrent requests) with 
the following layout. 



Figure 1.5.2. 1.2 DATA ACQUISITION REQUEST FORMAT 


| REQUESTORS MAILBOX ADDRESS | 

1 1 

(PARAMETER LENGTH 

1 

1 

_L_ 

RECORD_LENGTH | 

| PERIODIC/APERIODIC 

1 

1 

PERIOD | 

| HISTORY REQUEST 
1 

1 

1 

HISTORY JLENGTH | 

| UNIQUE RECORD 

1 

NAME | 


The REQUESTORS_MAILBOX_ADDRESS is an object name where the ODBMS can 
request further information about the subsystem storage requirements . The 
PARAMETER-LENGTH indicates to the ODBMS how many parameters are in the record 
and the RECORD_LENGTH indicates the number of bytes in the record . The 
Periodic/Aperiodic flag indicates if the record i3 to be sent to the ODBMS on 
a periodic basis or just once. PERIOD specifies the period in seconds. If 
the HISTORY_REQUEST flag is set, this indicates that back values are to be 
saved. If back values are to be saved, the number of back values is indicated 
in HISTORY_LENGTH . The UNIQUE_RECORD JIAME (URN) is the name assigned by the 
subsystem to identify the records that will be sent to the ODBMS. 

The ODBMS then sends a message to the requestor's mailbox address and 
requests a record definition to be returned. The record definition contains 
the subsystem parameter object names and the number of bytes for each 
parameter (field length). The ODBMS then stores this data in a parameter 
directory containing all unique object names (UON) available from the ODBMS. 
(See Figure 1.5.7. 1.5) Each object name is limited to 32 characters . 

Figure 1.5.2. 1.3 SUBSYSTEM PARAMETER DEFINITION 


| SUBSYSTEM-OBJECT-NAME-1 

1 

Field - 1 


| SUBSYSTEM-OBJECT-NAME-2 

1 

1 

1 

1 

Field - 2 
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The ODBMS sets up a mailbox to receive the data record from the subsystem 
and also establishes a memory space for the historical data on mass storage. 
The historical data is maintained in a circular file. Each record from the 
subsystems has the following format: 

Figure 1.5.2. 1.4 RECORD FORMAT 


UNIQUE - RECORD - NAME 

UON 1 

UON 2 


Figure 1.5. 2. 5 HISTORICAL RECORD FILE 


Curr. Record 

Pointer 
Next Record to 
be Overwritten 


RECORD f K— 1) 


RECORD (2) 

RECORD (1) 

RECORD (HISTORY-LENGTH) 

RECORD (K) 


* N 1 Records 
In File 


When the records received reach the HISTORY-LENGTH, then the pointer 
wraps around and several alternatives exist. If an archive history file is to 
be maintained for this subsystem record, then at each pointer wrap, the total 
history file could be telemetered to a ground data base for archive storage. 
The ground data base would be informed of the data content by a similar 
mechanism to the subsystem interface to ODBMS. Alternatively, each record 
could have been telemetered immediately that the current record was updated by 
the subsystem for ground operational DB support. 


The ODBMS could then accept requests to retrieve data from the parameter 
catalog on an UON basis. The current value can be requested or any number of 
historical records up to HIST-LENGTH. 
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Figure 1.5.2. 1,5 ODBMS PARAMETER DIRECTORY 


UOIM | 

UONo 


HISTORY-RECORD-LOCATION i | CURREMT-RECORD-POIWTER 
HISTORY-RECORD-LOCATIONI I CURRENT-RECORD-POINTER 

— I 
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System Integration Test & Verification (SITV) Trade Study 


1.0 Trade Study Definition 

1.1 Purpose of Trade Study 

To identify the preferred options for the Integration, Test and Verification 
of the Space Station Data System (SSDS) elements, consistent with the SSP 
mission and programmatic goals. 

1.2 Background 
1.2.1 General 

The operational SSDS will consist of Ground and Space segments, each designed 
to meet the functional allocation of the SSDS requirements, and linked, at 
least initially, via the TDRS system. The integration, test and verification 
effort for these segments, both individually and in combination encompasses a 
number of significant options to be addressed in this trade study activity. 

A reference model for the over-all effort is provided in Figure 1. The intent 
of this figure is to identify the significant Integration and Test levels to 
be addressed while also providing a top-to-bottom chronology. As shown in the 
figure, it is prerequisite that the Ground Segment be operational to fully 
support pre-launch and on-orbit activities of the Space Elements. The Ground 
segment will interface with existing/modified institutional facilities to 
provide the data/command management (distibution, processing, archiving, etc), 
mission control and scheduling, and configuration management functions. It is 
anticipated that the Ground segment will utilize primarily commercially 
available equipment that can be emplaced and activated with few, if any, 
difficulties. Target, or functionally representative hardware will be 
available, based on well supported commercial product lines, to accommodate 
software development requirements . 


13-1 



SPACE SEGMENT 


GROUND SEGMENT 


Development 

Acceptance, 

A Qualification 
Level 


SSDS Level 
Integration 


Launch 

Package 

Integration 


Station 

Build-Up 



Figure 1. SSDS Integration & Test Overview 


The space segment acquisition presents considerably higher technical risks 
because of the need for orbital assembly and activation, the limited Station 
accessibility, and the space environments. Preliminary concepts for the 
On-board SSDS design have proposed a distributed, networking configuration; it 
is anticipated that processing nodes (combinations of processors, network 
interface units, and mass storage devices) will be embedded into the various 
modules and structural elements of the Space Station. These nodes, supported 
by man-machine-interfaces (workstations), and interconnected by an appropriate 
network design with an interface to the Communication and Tracking sub-system, 
must support the full functionality of the IOC Station yet must be compatible 
with a coherent and efficient build-up phase. 

The current build-up concept, as discussed in Task 1, Section 4.4.3, proposes 
at least seven launch packages (driven by NSTS cargo weight and volume 
compatibility) to be boosted to orbit in a logical sequence for incremental 
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assembly into the IOC Station. As depicted in Figure 1, it is anticipated 
that the On-board SSDS hardware will be integrated into its host launch 
package and checked out prior to launch. 

The acquisition phase environment for the SSDS will be one in which its H/W 
and S/W products are procured/developed and delivered by multiple sources. 
These deliveries may be chronologically staggered to match the build-up 
sequence and to reduce peak funding requirements . The concept of staggered 
deliveries may impact apparent goals to verify all Space Segment flight 
interfaces prior to launch however in some cases this goal may prove to be 
less than practical and in other cases may be unnecessary. Payload 
interfaces, for example, may fall into the latter category on the basis that 
such interface must be standard/common; during ground integration testing of 
the on-board system, a generic payload simulation should be sufficient, from 
an SSDS perspective, to establish the interface compatibility. A symmetrical 
verification will suffice for the general payload. 

The factor of multiple contractors adds considerable complexity to the system 
integration effort, particularly when sub— systems may be distributed, not only 
across different modules and structural elements but also across the 
contractual work packages. Commitment to an effective program of 

standardization and commonality will significantly reduce the number of unique 
hardware configurations and interface protocols. Any resulting penalty in 
operational efficiency will be more than offset by a cost payoff in the form 
of reduced development, certification, test equipment and fixtures, and spares 
requirements . The standards however must be sufficiently defined to preclude 
interface incompatibility between different contractor implementations. 
Standardization on specific programming and user interface languages will 
provide a second level of efficiency through, a) minimization of software 
support requirements , b) establishment of source and object code libraries, 
and c) reduction of expertise requirements . 

In summary, the Integration, Test, and Verification and implemented 
procurement strategies will be interdependent; cost optimization must, in 
fact, be a marriage of options from both. 
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1.2.2 Ground Segment Concepts 


It is recognized that there are significant design/configuration issues 
associated with the SSDS ground segment. For example, incorporation of 
existing H/W and S/W capabilities with differing interfaces and protocols must 
be accommodated. Integration and Test concepts must be considered within the 
systems engineering tasks however the primary obstacle will be that of the 
design. Problems will inevitably occur, however, the over-all acquisition 
will be relatively routine since: 

• There are few procurement constraints; environment/qualification is 
not an issue, and there are few, if any, critical weight, power or 
volume limitations 

• Equipment/facility accessibility is not a problem. 

• The major SSDS elements will be dedicated and can be 
integrated/activated with minimal operational interference with 
existing facilities. 

Since no significant Integration and Test issues for the Ground Segment have 
been identified, this segment will not be specifically addressed further in 
this trade study effort. 

1.2.3 SSDS Space Segment 

The typical space flight hardware has virtually no post launch accessibility 
and must be in at least a near-operational configuration at launch since this 
hardware typically has minimal automated or remote reconfigurability . 
Conservative test programs are therefore dictated that provide comprehensive 
demonstations of operational effectiveness and suitability, and include full 
"all-systems" integration testing on the operational configuration. Following 
comprehensive all system testing, the integrity of flight interfaces must be 
maintained (or re-established) through pre-launch checkout and flight. 

The Space Station, in contrast, will be incrementally boosted to and assembled 
on orbit. It will be accessible on at least a limited basis during build-up 
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(and man-tended phases) and will be fully accessible as a manned facility. 
These differences imply that individual launch packages need not be 
constrained to an operational configuration for launch. Also, the noted 
accessibility implies a maintainability such that a large variety of equipment 
problems identified during build-up and activation can be corrected on orbit. 
It is therefore concluded that: 

• Hardware susceptible to the NSTS environments yet compatible with the 
Station environments could be provided with special 
handling/packaging for NSTS launch/re-entry operations, and, 

• Reduced MTBF requirements may be tolerable, particularly with the 
NASA imposed fail op/fail safe/restorable design requirements . 

Strategies to reduce the rigorous environment/interface compatibility tests 
and repetitive performance demonstrations are therefore viable to cost 
optimize the Integration, Test and Verification against acceptable risk 
profiles. It is this theme that is pursued in this trade activity. 

1.2.4 Test Definitions 

To clarify the discussions of the subsequent sections, test definitions for 
the standard test sequence are provided in Appendix A of this study. 

1.2.5 Acceptance and Qualification Test Concepts 

The Task 2 System Test, Integration, and Verification options paper discussed 
the following acceptance and qualification test deviations to the 'standard' 
industry approach: 

a) Deferment of selected sub— assembly functional and environmental 
testing to the next (assembly) levels. 

b) Deletion of selected (e.g. thermal vacuum) environmental tests during 
module acceptance testing, and. 
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c) Modification of traditional certification (qualification) testing 
profiles (levels and durations) to support protof lighting, thus 
minimizing non-flight hardware costs. 

These deviations are consistent with the above theme of reduced conservatism 
and are thu3 the preferred approach almost by inspection; option (c), in fact, 
is effectively a given. Since these deviations can only be discussed from a 
relatively high level and on the basis of generic hardware, they are not 
readily decomposed into sub options to be traded. Therefore, acceptance and 
qualification testing will not be addressed further in this study activity. 

1.2.6 Verification Concepts 

As indicated by the Appendix A definition, the System Verification effort will 
be distributed across all levels of the ground testing; in addition, since 
some Space Station operational testing may not be practical or feasible in a 
lg environment, the verification program must be completed during the on— orbit 
activation sequences. 

The goals of the verification program are to not only insure design compliance 
but to efficiently, and cost effectively, provide early and comprehensive 
identification of discrepancies. Design compliance must address operational 
suitability requirements , e.g. reliability, safety, and maintainability, etc. 
in addition to the normal functional, performance, and compatibility 
requirements . The typical verification program therefore overlays and expands 
on the normal test sequence of the first production units. In general, 
however, the verification activities adhere so closely to the structure and 
policies of the underlying tests that separate issues with respect to depth 
and degree of testing, facilities requirements, and costs can not be 
differentiated. Options/trades for the verification effort have, therefore, 
not been generally addressed. 

The single exception is the performance of an SSDS end-to-end (Space and 
Ground) verification. Such a verification appears to be favored to insure 
full end— to— end compatibility prior to launch. The concept implies 
interconnection/assembly of several launch packages to provide an operational 
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capability such that the Ground System can operation and monitor selected 
’on-orbit' sub-systems and payloads through the TDRSS link. This option may 
be unwieldy however with respect to the Space Segment because of the 
assembly/tear down operations, the increased facility requirements, and the 
potential impact on the TDRSS/Nascom resources. A piece— meal, more 
independent approach may be more viable and still provide sufficient 
confidence. This issue is discussed and the options traded in Section 3.0. 

1.2.7 Integration/Test Concepts 

The integration/test process assembles and links hardware and software 
entities to form partial or complete systems with specified functional 
capabilities which are then verified. This activity will generally be 
accomplished through incremental addition of products until a required level 
of functional capability is achieved and verified. The definition of these 
products may vary widely depending on procurement packages/contracts and will 
impact the development/integration methods. Generally, these products can be 
characterized as : 

a) S/W Packages - separately developed software packages that have been 
tested in a 'stand-alone' mode using a target machine, emulator or 
functional simulator, 

b) Hardware Components - separately procured/developed hardware items 
that have been previously acceptance tested and certified. It is 
generally assumed that the integration of separately procured 
computers and software packages is accomplished prior to integration 
and not included in this definition. Examples are hardware items 
such as time frequency generators, network media, and Will's, or, 

c) Integrated Hardware/Software - separately developed "subsystems" that 
include software already integrated with internal hardware 
components, i.e. computers, mass storage, etc. When multiple 
computers are required for a 'subsystem' entity, it is assumed that 
the same level computer integration testing is performed prior to 
integration. However, full integration of subsystem computers may 
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become a SITV function depending on availability of network hardware 
to the subsystem contractor. 

One of the more technically challenging aspect of the On-Board SSDS design 
described earlier will be the distributed operating system, (DOS). The DOS 
will be developed in software modules corresponding to each of the processing 
nodes and software interfaces will be verified using either target hardware or 
emulators as indicated in Figure 1. An integration of hardware and software 
will occur at the next (SSDS) level; however, there appear to be two basic 
approaches. One option is to perform a full sub-sy3tem test utilizing a 'test 
bed' to interconnect all processing nodes. A second approach would be a 
segmented approach, testing each processing node individually and simulating 
the remainder of the subsystem. The key issue of these options is whether a 
full verification of the distributed operating system (DOS) is necessary at 
this relatively low integration level. 

At the next (launch package) level, the sub-systems and structural elements 
including the SSDS will be assembled into their functional elements, primarily 
associated with launch packages. Clearly, each individual package will 
require a comprehensive Integration/Test effort, however, there is also some 
consideration for a more inclusive pre-launch integration of the over-all 
Station. The available options, analogous to those at the SSDS level, are: 

1) A "segmented" approach wherein the integration is limited to the 
hardware and software associated with each launch package; the 
interfaces to the rest of the Space Station and ground would be 
simulated, and, 

2) An "all systems" integration of the full Station wherein all 
subsystems and structure are assembled/interconnected to the 
maximum practical extent to demonstrate the 'full' SSDS 
capabilities . 

Clearly, the Station environments for the 'all systems' approach will limit 
structural deployment and some sub-system functionality, however there is 
precedence and program benefit for such large 'all systems' exercises. 
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Growth, with respect to the SSDS will provide vertical and/or horizontal 
expansion of capabilities, including added autonomy. Effective systems 
engineering will define the appropriate interfaces for the over-all system 
vertical/horizontal hierarchy such that hardware and software entities can be 
added and replaced with minimal impact to the remaining 'structure 1 . The 

J 

on-orbit Integration/Test effort will be a sequence of hardware (BIT) 
verification, interface compatibility checks, and functionality verification. 
There must be some ground preparation, however, to minimize the risk of the 
on-orbit activity. The options include: 

a) utilization of relatively high fidelity simulation or production 
spares if available, and, 

b) remote integration to the existing operational configuration 
utilizing the TDRSS links. 

The above integration/test and verification concepts are refined and traded in 
the following sections. 


1.3 Issues 

The issues to be addressed in this study activity are: 

• What ground integration effort should be performed on the isolated 
(on-board) SSDS? 

• What ground integration effort should be performed on the launch 
packages/Space Station (from the SSDS perspective) prior to launch? 

• What pre-launch SSDS end-to-end verification is appropriate? 

• What pre-launch integration effort should be performed on "growth 
phase" elements? 
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1.4 Trade Study Criteria 


The full set of criteria parameters and definitions for the subsequent trade 
analyses is tabulated below. The criteria listed is utilized for each of the 
trade analyses and has been assigned a weighting as shown in the tabulation. 

This weighting, as discussed in the Section 2.0 methodology, is an assessment 
of the relative impact of the parameter to the project success. 

• Cost (Weighting - 30%) 

• New Facilities - Cost of facilities if required to support the 
option . 

• Manpower - The manpower requirements of the particular option 

• Duration - The. relative time period required to complete the 
option 

• Test Equipment - the costs of test equipment including fixtures 
and software required to support the option 

• Schedule (Weighting - 25%) 

• The impact of the option on the overall program schedule 

• Risk (Weighting - 25%) 

• Technical - The relative technical difficulty/feasibility in 
completing the option requirements 

• Program - The potential impact to program achievabi lity based 
performing or not performing the option. 
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Suitability (Weighting: 20%) 


• Test Efficiency - The relative efficiency of the option, i.e. 
the effort expended vs the probability of detecting problems. 

• Safety Considerations - The relative personnel and equipment 
safety in the performance of the option testing. 

2.0 Trade Study Methodology 

For each of the trade areas, the following methodology has been applied. 

1) Fully characterize the options : Each option will be characterized as 

fully as possible to allow a fine grained assessment corresponding to each 
parameter of the criteria. 

2) Select an appropriate set of evaluation parameters : This set ha 3 been 

provided in Section 1.4. 

3) Provide weighting factors for each evaluation parameter : A weighting 

factor has been assigned to each parameter of the criteria set based on its 
relative impact to the project success. Cost, for example, is a relatively 
high impact parameter and will be assigned a higher percentage weight. 

4) Provide a numerical assessment for each option : A numerical assignment 

(0-10) will be entered in each option column, corresponding to each parameter 
of the criteria. This assignment provides a relative estimate of the 
suitability or effectiveness of the option based strictly on that parameter. 

A "10" indicates an excellent assessment; a "0" indicates a total deficiency. 
Note that inverse parameters, such as risk are inversely rated, i.e., higher 
costs and risks generate lower ratings. 

5) Score and rank the options : The parameter assignment times its 

weighting provides the option score for that element of criteria. The 
preferred option is identified by the largest criteria score sum. 
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6 ) Perform sensitivity analysis : An analysis will be performed to 

identify the key decision drivers. 

7) Re-evaluate individual trade activities : Each trade study will be 

evaluated to determine whether the results are reasonable and expected, to 
resolve and perceived inconsistencies, and to eliminate potential coupling of 
dependent issues. 

3.0 Trade Study Discussion and Results 

3 . 1 Ground Integration Effort for the SSDS 

3.1.1 Discussion 

As indicated earlier, the on— board SSDS will be a distributed, networking 
design utilizing processing nodes to support the sub— system requirements and 
the separable functions of the Data Management System. It is clear that the 
Distributed Operating System (DOS) must itself be subjected to exhaustive 
validation and verification, however, it is not as clear that the total 
onboard SSDS must be tested as a complete entity. The issue is what testing 
is required at the SSDS sub— system level to verify its readiness for 
subsequent integration efforts. The options noted in Section 1.0 are, 1) a 
segmented, individual processing node Integration and Test, and 2) a full 
system integration. 

For the segmented option, the integration/test would be essentially limited to 
the hardware and software associated with each individual processing node. 

The mechanical interfaces for the hardware would be simulated using fixtures 
that also supply electrical power and thermal control. The electrical and 
logical interfaces to the remainder of the SSDS (including the DOS) and 
sub-systems would be provided by simulation. This simulation could also be of 
benefit to the Verification Program since interface parametrics (voltage, 
impedances, timing) could be varied to demonstrate processing node 
compatibility margin. Appropriate diagnostic programs and stimulus would be 
provided to each processing node to verify its built-in test, fault detection, 
reconf igurability and performance. The response and output data from each 
node would be analyzed to insure it functionality. 
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The benefits of this option are the reduced facility requirements , since much 
of this simulation and fixtures would be common to each node. Also, this 
approach could more easily support a staggered development/delivery schedule 
that was 'launch package' oriented. 

The obvious disadvantage to this approach is the higher program risk in 
deferring the full integration to a higher level (possibly on-orbit) where 
detected design deficiencies or incompatibilities will have a more severe 
impact . 

The second option performs a full integration/test of all On-Board SSDS 
hardware and software. A test bed approach is anticipated to accommodate 
requirements for power, thermal management, etc. The complete local area 
network (LAIM) connectivity would be provided and all configurations, modes and 
automation/autonomy of the system could be demonstrated against diagnostic 
data/command traffic scenarios. Associated sub-system. Payload, 
sensor/effector interfaces would be simulated. The test requirements, 
procedures, and facilities would all be more complex; however, this option 
minimizes SSDS functionality risks at the next integration level. 


3.1.2 Criteria Evaluation 

The criteria parameters associated with these options are briefly discussed in 
the following paragraphs. 

• Cost 

It appears that option 1 will generate the lower cost. Fixturing will be 
required for the mechanical, electrical, and logical simulation of the 
processing node interfaces however, fixture(s) may be common for many, if not 
all, of the nodes. The simulation effort, i.e. subsystem and remaining SSDS 
interfaces, should not be major and may in fact be part of a coherent test aid 
complement provided for the development contractors. 

The manpower requirements cannot be differentiated; option 1 may require a 
fewer people for an extended period while option 2 would require a shorter 


13*13 



period with but with perhaps a higher personnel count and more complex 
documentation . 

• Schedule 

Option 1 would provide the more compatible schedule with' the staggered launch 
package flight schedule. Also this approach provides an inherent flexibility 
in that testing could shift to another processing node if the node under test 
failed and required some time to disposition. 

• Risk 

The technical risk would perhaps be somewhat higher with option 2 due to the 
larger set-up requirements but is not a key discriminant in the performance of 
either option. The program risk is higher with option 1 since actual 
(functional/logical) interfaces will not have been verified and the 
distributed operating system will not have been fully demonstrated prior to 
proceeding to the next integration level. 

• Suitability 


Option 2 is clearly more suitable since the actual system interfaces and 
functionality is test with a minimum of simulation. Noted discrepancies will 
therefore, in general, be real and not by products of the simulations. Safety 
is not a concern for either option. 

3.1.3 Results 

As shown in Table 3.1 - 1, the "full system" option is preferred . The 
sensitivity analysis shows risk to be the key evaluation factor. 

3.2 Ground Integration Effort For The Launch Modules 
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TABLE 3.1-1 


3.2.1 Discussion 

As discussed earlier, the Space Station design must accommodate separable 
launch packages for incremental boost to orbit and assembly. It is 
anticipated, however, that each package will be fully integrated on the ground 
as indicated in Figure 1, i.e. corresponding SSDS segments will be 
installed/tested and will remain part of that launch package. The actual 
launch configuration of these packages will, however, be a compromise based on 
Orbiter Cargo Bay volume and weight constraints, the goal to minimize EVA 
time during build-up, and special handling requirements for any launch 
environment susceptible hardware. 

It is anticipated that this launch package level integration will occur at a 
KSC facility to minimize subsequent handling prior to launch and because of 
potential use of existing facilities. 
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Like the SSDS level integration activity, there are two primary options on the 
Space Station plane. The first is the segmented approach, where in the 
integration is limited to individual launch packages. The second option is 
that of a full 'all-systems' ground integration/test effort. 


For the first option, all hardware and software, electrical power, thermal 
management, ECLSS, communications, etc. associated with the launch package 
will be implaced and activated with fixturing and simulation provided to 
duplicate the interfaces of the remaining launch packages. This approach has 
some significant advantages in that: 

• Facilities and manpower requirements are minimized, and, 

• It accommodates a schedule of staggered development/deliveries that 
will in all likelyhood, more closely match NASA fiscal funding plans. 

The primary disadvantage of this option is that the actual interfaces and 
global functionality verification is deferred to the On-Orbit integration 
activity where discrepancies can result in serious program pertubations . 

For the second option, all launch packages will be assembled/interconnected 
using special fixtures, extension cabling, etc. Although some structural 
deployment and sub-system functionality could not be fully demonstrated in a 
lg, ambient pressure, ambient temperature environment, considerable confidence 
can be gained in exercising the sub-systems/ launch packages together. This 
option would not only support full checkout of operating modes but would also 

support crew training and preliminary development of crew schedules and 
mission timelines. 

The disadvantages of this second approach are the requirements for additional 
handling, massive facilities, more complex test documentation, greater 
manpower and inherent inefficiencies. 
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3.2.2 Criteria Evaluation 


The criteria associated with each of the options is briefly discussed in the 
following paragraphs . 


• Cost 

Option 1 would require the lower costs because of the lesser facility 
requirements, and more manageable manpower requirements . 

• Schedule 

Option 1 is considerably more compatible with the over-all program and allows 
a staggered integration effort that aligns with the build-up sequence. This 
approach would allow staggered development and/or delivery of launch package 
products that would be more compatible with NASA fiscal funding plans. 

• Risk 

• Option 1 represents a higher program risk because of the 
delayed/deferred assembly and test of the actual interfaces and the potential 
of discovering deficiencies and/or incompatibilities on orbit. Option 2 
presents a higher technical risk in attempting to assemble and test all launch 
packages . 


• Suitability 

Option 2 is less efficient since inevitable problems with any elements (launch 
packages) will result in test downtime. In the segmented approach, there is 
the potential of reconf iguring to another launch package (being prepared in 
parallel) for testing. The necessary structural complexities and facility 
support requirements will generate somewhat greater hazards for the flight 
hardware and test crew. 
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3.2.3 Results 


As shown in Table 3.2-1, the segmented approach is preferred. Sensitivity 
analysis show cost and schedule to be the key discriminants. 


3.3 Pre-Launch End-To-End SSDS Verification Effort 
3.3.1 Discussion 

The Space Station Data System represents considerable complexity, not only in 
the On-Board functionality but also in the data and command transport between 
the payload/experiment on-orbit and the customer on the ground. The 
data/command flow paths include the On-Board LAN, the ground UIAN and the 
intervening TDRSS/Ground Station link. The end-to-end transport must support 
packetized data formats (encrypted as required), error protection techniques. 
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flow control techniques, and distribution based on packet header addressing. 
Verification of the data transport has two primary options: 1) a piece-meal 
approach that verifies sections of the transport path independently and 2) an 
integrated end-to-end approach. 

J 

Option 1 relies heavily, of course, on simulation and minimizes impact on the 
institutional facilities. The On-Board verification will utilize simulation 
to provide the desired diagnostic data to the inputs of the element (launch 
package) under test to simulate 3ub-system, payload and DMS data/commands; the 
returned (forwarded) data/commands will be analyzed to insure the proper 
handling . 

The On— Board Communication & Tracking (C&T) Subsystem/TDRS interface is 
critical. This interface will require comprehensive checkout to insure S-Band 
and K-Band compatibility and at some point, bit error rate (BER) tests will be 
required. The TDRSS has compatibility test capabilities available via 
permanent and mobile van systems that can utilize TDRSS ground simulation 
support and also provide direct links to the TDRS. Some of this checkout may 
be performed to the C&T sub-system level and/or at the pre launch Space 
Station level. 

The SSDS Ground segment can demonstrate its processing, storage, and 
distribution capabilities through insertion of diagnostic data into the head 
end of the system (Ground Station) either directly or via a 'loop back' 
capability to TDRS, and monitoring the subsequent data processing and 
distribution activity. 


The intent of option 2 is to perform an end-to-end verification of the 
combined paths in as close to operational configuration as possible. For this 
approach a TDRS SA antenna would be slewed down to the C&T antennas to provide 
what would normally be the 'space-space' link, as depicted in Figure 2. The 
TDRSS/Ground SSDS segments would assume normal operational configurations. 

It is recognized, however, that there may be severe limitations in assembling 
the total Station as discussed in Section 3.2.1. In the minimum case, the 
'Station' may consist of only the Comm & Tracking sub— system and its 
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Figure 2. Prelaunch Gnd-to-Gnd Verification 


associated launch package(s) with some interfacing DMS elements. The 
remainder of the Station, (as required), platforms and payloads, would, most 
likely, be simulated. Another difficulty is that the operational C&T antennas 
and their supporting trusses may not be deployable in the lg environment. 

Thus, non-flight antennas may be required to link to the TDRS. In summary, 
although there is some added confidence to be gained, ground verification of 
the end-to-end system has some dis-advantages in that: 

• the full end-to-end capability is not practical; much of the On-Board 
SSDS would be simulated, 

• Comm & Tracking Sub-system antennas/mounts are anticipated to be a 
non-flight configuration. 

• this option may impact TDRSS if allocated Space Station resources are 
not in place, i.e. additional TDRS's, and Ground Station. 
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3.3.2 Criteria Evaluation 


The criteria associated with these options are discussed in the following 
paragraphs . 

• Cost 

Option 1 testing will, in all likelihood, be performed in any case which 
categorizes all of the Option 2 costs as additional. 


• Schedule 

Option 1 provides more schedule flexibility since the ground and space paths 
could be verified independently. 

• Risk 

Technical risk is not a discriminant for either option. There is a decrease 
in program risk with the performance of Option 2. 

• Suitability 

Option 2 is considered to be less efficient based on the magnitude of the 
effort and coordination required to perform the test. Safety is not 
considered an issue. 

3.3.3 Result 

As shown in Table 3.3-1, the segmented approach is preferred. Sensitivity 
analysis shows cost and schedule to be the key discriminants. 

3.4 Pre-Launch Integration Effort For Growth Phase Elements 
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OPTION 2: 


xxxxxxxxxxxxxx: 



3.4.1 Discussion 

Growth phases are planned for the Space Station/SSDS in support of larger 
complements of payloads/experiments. This growth will result in additional 
structure, HAB/LAB modules and over-all data/command handling capability. 
Physical integration of the additional hardware and software with the existing 
Station mu3t necessarily be performed on-orbit, however, there are options for 
ground activity in preparation for this integration. Program policies cannot 
be predicted, however, a high fidelity simulator/mock-up, provided on previous 
programs, is not anticipated. This assumption removes the possibility of a 
comprehensive ground integration. Instead, simulators and fixtures utilized 
in the IOC acquisition phase will be available/modifiable for use. There are, 
however, options for verifying the functional/logical interfaces of the growth 
elements . 
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The first option employs the approaches and lessons learned from the IOC 
acquisition experience through the use of simulators to verify the 
functional/logical interfaces of the new elements independent of the existing 
operational Station. The second option is to utilize the TDRS link to more 
directly verify the interfaces to the Station. 

Option 1 needs little discussion since it has been addressed at length earlier 
in this paper. 

Option 2 provides an (indirect) interface with its associated Station 
elements. From a logical perspective, this approach provides an advantage in 
that simulation errors are not involved, however, the link delays may result 
in severe disadvantages. As noted earlier, the integration effort is presumed 
to occur at KSC, therefore the multi-path link from KSC to the Space Station 
and return, could involve delays of several seconds which may impact the test 
feasibility. This option has the additional dis-ad vantages that Station 
configuration/scheduling pertubations would be necessary thus potentially 
impacting planned operations, and the additional TDRSS traffic could be an 
impact to the Station and other projects relying on the TDRSS resources. 

3.4.2 Criteria Evaluation 

The trade study parameters associated with these options is discussed in the 
following paragraphs . 

• Cost 

The activities of option 1 would be performed to a large extent whether in 
preparation for option 2, thus the option 2 costs (man-power, TDRSS, WAN) must 
be considered additional. 

• Schedule 

Option 2 would be dependent on the Station and TDRSS scheduling where-a 3 
option 1 could be performed independent of any ongoing operations. 
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Risk 


• 

There is some risk to the option 2 approach in that identified discrepancies 
could impact the Station. Option 2, if successful however provides a lower 
over-all risk to the success of the integration. 

• Suitability 

Suitability is not a discriminant for either option. 

3.4.3 Results 

As shown in Table 3.4-1, the independent integration approach is preferred on 
all criteria. 
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Appendix A - Testing Sequence Definitions 


DEVELOPMENT - Engineering evaluation tests of various integration levels of 
H/W and S/W products. The effort is intended to assist design engineering in 
evaluating/validating proposed design solutions. This testing is not 
generally subject to the rigors and documentation formality associated with 
production flow testing unless, (consistent with the protof lighting concepts), 
potential mission operational hardware is utilized. Specific NASA Test Beds 
will be available to support development tests. 

CERTIFICATION - Effectively synonomous with Qualification testing, this 
effort includes those tests and analyses required to demonstrate that design, 
materials and components, and manufacturing processes will perform in the 
mission operational environment. Testing generally consists of functional 
tests in conjuction with environmental exposures to profiles more severe than 
those projected for the mission. Analyses may substitute for tests to reduce 
costs and support protof lighting when product and environments can be 
adequately modeled. 

ACCEPTANCE - Testing performed generally at vendor facility to assure that the 
equipment meets delivery requirements and to demonstrate a readiness for the 
next integration level. Includes functional performance and environmental 
exposures to demonstrate immediate capabilities of specific hardware and to 
screen out faulty components and workmanship not detectable through inspection 
techniques . 

SOFTWARE VALIDATION/VERIFICATION - This effort, performed by the vendor or by 
an independent agency, is a review of the software design requirements and an 
exercising of the generated solution, within specified bounds, to demonstrate 
conformance to those requirements . 


INTEGRATION - The process of combining H/S and S/W elements into specified 
configurations, verifying physical and logical compatibilities, verifying 
functionality and performance, and insuring that the configuration is ready 
for the next integration level. This effort is performed at specified (not 
necessarily the launch) site(s). This integration may utilize physical 
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mock ups, interface simulation, and access to processors for automation and 
maintainability verification. 


VERIFICATION - The test/analysis program that proves system conformance to 
design, performance and suitability, e.g. safety, maintainability, reliability 
and environmental compatibility requirements. This effort is necessarily a 
distibuted operation that relies heavily on development, acceptance, 
certification, flight demonstration, preflight checkout testing augmented by 
analysis. This effort is normally a one time requirement and may expand the 
scope of normal test sequences for an early production article. 

LAUNCH READINESS - The effort of verify ing/servicing launch packages in 
preparation for boost to orbit and subsequent operations. This effort may be 
a multi-phase operation to: 

• verify no shipping damage on delivery to launch site 

• perform a limited checkout while in the orbiter bay. 
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XIV. CREW WORKSTATION 


14*1 



2.0 CREW WORKSTATION TRADE STUDY 


The following trade studies analyze display type, color displays vs. mono- 
chrome, input controls, and caution and warning techniques for use in the 
NASA Space Station Crew Workstation. Figure 2.0 depicts the logic flow 
followed for each trade study. Initially, all NASA RFP requirements, NASA 
reference configurations, NASA standards, and independent technical studies 
are consolidated and analyzed to determine a viable set of options. The 
majority of this work was completed under Task Two, the options phase. 

Using the NASA crew station RFP input requirements and program goals as listed 
in Table 2.0, a set of selection criteria is determined for each trade 
study. This selection criteria is the basis for which technology will be 
chosen. For each selection criteria a weighting factor is assigned that 
determines its relative importance to the Space Station program. Each 
option is also assigned a relative weighting factor with respect to the 
other options for a specific selection criteria. This relative weight- 
ing factor (0 - 10.0) defines, in a qualitative manner, the relative good- 
ness of an option with respect to the other options for a specific 
selection criteria. The relative weighting is multiplied by the weighting 
factor and summed across all selection criteria for each option. The 
result is a figure of merit and indicates the most desirable, through the 
least desirable option, with respect to the Space Station program. In order 
to perpetuate an "intuitive feel" for this figure of merit it is divided by 
a perfect figure of merit, i.e., all relative weighting factors equal 10.0. 
The figure of merit is still a comparison of the options and also can be 
thought of as a percentage of the optimal technology. 
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TRADE STUDY LOGIC FLOW 
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STUDIES 








TABLE 2.0 


CREW WORKSTATION DISPLAY & CONTROLS RFP REQUIREMENTS 


MPAC RFP REQUIREMENTS 

C5 2.2.5.1c DMS General Rqmts, Opnl Intfcs 
The operational interface to the DMS shall be through the 
Multipurpose Application Consoles (MPAC) and the distributed 
computer processing system. 

C5 2.2.5.3.C DMS Dsgn and Perf Rqmts 

The fixed and portable MPAC shall be a common design function 
ing as a man/machine interface to the network operating 
system. The MPAC shall provide command and control, monitor- 
ing, operations and training capabilities. Furthermore, the 
MPAC shall provide: 

1. Visibility into all subsystems. 

2. Simultaneous viewing of displays. 

3. Crew override for subsystem operations. 

4. Annunciation for catastrophic failures, consistent 
with established caution and warning philosophy. 

The MPAC shall consist of the necessary displays, monitors , 
interactive controls and recording devices . The portable 
MPAC shall support both EVA and IVA operations. 





TABLE 2.0 


CREW WORKSTATION RFP REQUIREMENTS (continued) 


• C5 2.2.5.3.C DMS Dsgn and Perf Rqmts 

The fixed and portable MPAC shall be a common design function- 
ing as a man/machine interface to the network operating 
system. The portable MPAC shall support both EVA and IVA 
operations. 

• C5 2.2.11.1.d EVA Functional Rqmts 

Portable workstations shall be designed for use with unpre- 
pared work sites . 

• C3 3.2.d Sys Dsgn Featrs, Common, Rel and Maint 

A flight data file for crew use during IVA and EVA operation 
through portable work stations shall be provided. This 
system shall be complemented by IVA hardcopy devices as 
appropriate. 
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TABLE 2.0 


CREW WORKSTATION RFP REQUIREMENTS (continued) 


• C5 2.2.10.1a Hab/Man Sys, Sys Integ, Standardization 

Crew interfaces and associated equipment shall be standardized 
throughout the Space Station. Crew stations with multiple 
uses shall be used. Markings and labels shall utilize 
international standards/symbols throughout all modules. 

• C5 2.2.10.1e Hab/Man Sys Sys Integ Dsps & Cntls 
Multifunction displays and controls shall be used. The 
following shall be designed to facilitate human productivity: 
character size, display brightness and contrast, auditory 
characteristics; control size, direction of motion, and types 
of controls; display format characteristics such as use of 
color, color controls, including tactile, visual , and auditory 
feedback requirements. Emergency operation of controls shall 
have a shape, texture, and location that is readily identi- 
fiable in the dark . The use of manually operated switches 
shall be minimized . Controls shall be protected against 
inadvertent operation . 
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TABLE 2.0 


CREW WORKSTATION RFP REQUIREMENTS (continued) 


• C5 2.2.10.2a Hab/Man Sys, Crew Statns, Work Statns 

A crew station shall be defined as any location in the Space 
Station where a dedicated task or activity is performed. A 
work station is a crew station which is exclusive of 
recreation, personal hygiene, food preparation, dining, 
housekeeping, and other off-duty activities. Accepted human 
factors engineering practices and criteria shall be used to 
design the human interface with the individual work stations. 
A thorough analysis of the requirements shall be done for 
each work station to determine the task, operator activities, 
level of automation, tools, equipment, etc. necessary to 
meet the requirements. Each work station shall meet the 
baseline safety requirements for the Space Station and will 
provide utility power . Work stations equipped to perform 
identical tasks (e.g., station housekeeping functions) shall 
utilize prime/backup logic with appropriate safeguards 
against dual functional path commanding, these work stations 
shall also satisfy the fail-safe criteria. 
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TABLE 2.0 


CREW WORK STATIONS RFP REQUIREMENTS (continued) 


• C5 2. 2. 10. 2. b Crew stations/Window Work Stations 

All work stations associated with windows for operation and 
scientific research shall have provisions for the following 
items where dictated by the requirements analysis: display 
and keyboard . 

• C3 3.1.3 Command, Control and Comm Support 

The information and data management services shall provide 
presentation services adequate to accommodate customer require- 
ments. Access to the services shall be provided through 
standard network interface nodes and attached work stations. 
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TABLE 2.0 


CREW WORK STATIONS RFP REQUIREMENTS (continued) 


4. 4. 4. 2. 1.2 Multipurpose Applications Console (MPAC) 

Fixed MPACs shall be used for routine operations. Portable 

MPACs shall handle operations away from the fixed units such 
as maintenance or operations where direct outside viewing 
through a window is desired. Both MPAC types will have 
multifunctional display screens and programmable controls. 

Resident in the fixed MPAC will be the capability to print 
data and graphics from the display screen. The crew will 
have the capability to plot timed events data which will be 
selected from the MPAC. The operator will be able to choose 
between raw and processed data. In addition, a method for 
recording video images will be provided. 

The design of the MPAC must take into account the zero-g 
environmental effects and astronaut positions. Granted that 
a local vertical is desired, a one-g rigidity in the design 
may not be desired. For example, the display screen may be 
positioned to any astronaut orientation. 



TABLE 2.0 


CREW WORK STATIONS RFP REQUIREMENTS (continued) 


• 4.4.3 .A Video System 

The configuration, safety, and functional requirements of 
the Station call for control stations in each habitable 
module so that different crewmembers can perform their 
required tasks with minimal or no interruption to or from 
others. The system will be simple to operate since there 
will be a large number of users specialized in many different 
fields and special training for Space Station equipment is 
kept to a minimum. 

These requirements drive the design of the television system 
to a distributed control system where camera controls, video 
switching, and other system functions will be controlled from 
any workstation or monitoring location. This distributed 
control station concept will allow continuous operation even 
if parts of the Station became uninhabitable. These work- 
stations will incorporate user-friendly input devices such 
as touch screen sensors, joysticks, and voice control inputs 
used in conjunction with color graphics generated menus and 
displays. The capability to move TV monitors from one 
location to another will be incorporated. 
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2.0.1 DISPLAYS SELECTION 


2. 0.1.1 Display Media Selection Criteria 

The following lists each selection criteria that will be used in the dis 
plays media selection trade study. The selection criteria are divided 
into eight generic categories; programmatic considerations, perform- 
ance parameters, risk assessment, maintainability, user-friendly, 
reliability, safety and operations support. These selection criteria 
are based on requirements and program goals set forth in the NASA RFP. 
Trade unique criteria were determined by independent technology re- 
search and defined in the Task Two Options Development Phase. 

Programmatic Considerations 

A. IOC Cost 

B. Life Cycle Cost 

C. Schedule Impact 

Performance Parameters 

A. Power 

B. Volume 

C. Contrast Ratio 

D. Resolution 

E. Driving Voltage 

F. Ruggedization 

G. Uniformity 

H. Temperature Range 

I. Color Capability 
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Risk Assessment 


A. Technology State-of-the-Art 

B. Producibility /Availability 

Maintainability 

A. Repairability 

B. Replaceability 

User-Friendly 

A. Readability 

B. Response Time 


Reliability 

A. Failure Rates 

Safety 

A. Failure Modes 

B. Radiation Tolerance 


Operations Support 
A. Testability 

Commonality 

A. Application 
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2. 0.1. 2 Display Media Selection Weighting Factors 

The following lists each weighting factor associated with each selec- 
tion criteria used in the display media selection trade study. These 
weighting factors were determined by a panel of Sperry space station sys- 
tem personnel in conjunction with NASA RFP requirements emphasis. 

Programmatic Weighting Factors 

A. IOC Cost Weighting Factor = (0.8) 

B. Life Cycle Cost Weighting Factor = (0.8) 

C. Schedule Impact Weighting Factor = (0.3) 

Performance Weighting Factors 

A. Power Weighting Factor = (0.6) 

B. Volume Weighting Factor = (0.6) 

C. Contrast Ratio Weighting Factor = (0.4) 

D. Resolution Weighting Factor = (0.1) 

E. Driving Voltage Weighting Factor = (0.6) 

F. Ruggedization Weighting Factor = (0.7) 

G. Uniformity Weighting Factor = (0.1) 

H. Temperature Range Weighting Factor = (0.7) 

I. Color Capability Weighting Factor = (0.4) 

Risk Weighting Factors 

A. Technology State-of-the-Art Weighting Factor = (0.3) 

B. Producibility/Availability Weighting Factor = (0.3) 

Maintainability Weighting Factors 

A. Repairability Weighting Factor = (0.5) 

B. Replaceability Weighting Factor s (0.5) 
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User-Friendly Weighting Factors 


A. Readability Weighting Factor s 

B. Response Time Weighting Factor 

Reliability Weighting Factors 

A. Failure Rates Weighting Factor 

Safety Weighting Factors 

A. Failure Modes Weighting Factor 

Operations Support 

A. Testability Weighting Factor = 

Commonality Weighting Factor 

A. Application Weighting Factor = 


(0.4) 

= (0.4) 


= (0.5) 


= ( 1 . 0 ) 


(0.5) 


(0.4) 
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2.0. 1.2 Display Media Trade Study 

This trade study evaluates the use and desireability of the following 
display media for use in the Space Station Crew Workstations. 

A. Cathode Ray Tube (CRT) Display 

B. Plasma Flat Panel Display 

C. Light Emitting Diode (LED) Flat Panel Display 

D. Liquid Crystal Flat Panel Display (LCD) 

E. Electroluminescent (EL) Flat Panel Display 

Table 2. 0.1. 2 is the trade study results. Each display type and its 
associated selection criteria is given a qualitative rating within the 
display type set. Due to the rapid advancement in display technology 
and numerous displays which use each technology an overall assessment 
of excellent, good, fair and poor for each selection criteria is used. 

From the trade study results, the order of display media preference 
is: 

1. Liquid Crystal Flat Panel Display 

2. Cathode Ray Tube 

3. Electroluminescent Flat Panel Display 

4. Plasma Flat Panel Display 

5. Light Emitting Diode Flat Panel Display 

Table 2. 0.1. 2 is the acutal trade study results. The following lists 
the order of preference, and the total dot product of the weighting 
factors and trade parameters, for the display media options. 
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1. Liquid Crystal Flat Panel Display - 81.8 

2. Cathode Ray Tube - 78.4 

3. Electroluminescent Flat Panel Display - 76.2 

4. Plasma Flat Panel Display - 76.5 

5. Light Emitting Diode Flat Panel Display - 65.4 

A "figure of merit' is also calculated indicating the percentage of 
satisfying all selection criteria. These are as follows: 

1. Liquid Crystal Flat Panel Display - 68.74 

2. Cathode Ray Tube - 65.88 

3. Electroluminescent Flat Panel Display - 64.03 

4. Plasma Flat Panel Display - 64.29 

5. Light Emitting Diode Flat Panel Display - 54.96 

In general, the flat panel displays have an advantage over the CRT in 
the resource utilization department such as weight, volume, power and 
etc. The significant reason that the liquid crystal flat panel display 
is rated number one is that it also has color capability as does the 
CRT which is a close second. In reality either the CRT or liquid 
crystal flat panel display could be used on the NASA space station. 

The remaining flat panel technologies in all probability will not be 
suitable for the sophistication required for a space station display. 
Refer to the bar graph in Figure 2. 0.1. 2 for ease in viewing the trade 
study parameters in Table 2. 0.1. 2. 
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R.W. =6.0 

R. W. *W. F. = 
3. 6 


PRODUCIBI— 

LITY/AVAIL- 

ABILITY 


Excel 1 ent 

R. W. =10. 0 

R. W. *W. F. = 

6.0 


Good 

R. W. =6. 0 

R. W. *W. F. = 

6 . 0 


Good 

R. W. =6. 0 
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R. W. =6. 0 

76.5 / 119 

R. W. *W. F. = 

R. W. *W. F. = 

R. W. *W. F. = 
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R. W. =3. 0 

R. W. =6. 0 

65.4 / 119 
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4. 8 

= 54.96 
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R. W. *W. F. = 

R. W. *W. F. = 
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Figure 2.0. 1.2 
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Figure 2.0. 1.2 (cent.) 
Display Trade Study 
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Figure 2.0. 1.2 (cont.) 
Display Trade Study 
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Figure 2,0. 1.2 (cent.) 
Display Trade Study 
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2.0.2 COLOR DISPLAY VS. MONOCHROME 


2. 0.2.1 Color Encoding vs. Monochrome Display Selection Criteria 

The following lists each selection criteria that will be used in the 
color vs. monochrome display trade study. The selection criteria is 
divided into four generic categories; programmatic considerations, 
performance parameters, commonality considerations and risk assess- 
ment. These selection criteria are based on requirements and program 
goals set forth in the NASA RFP. Trade unique criteria were deter- 
mined by independent technology research and defined in the Task Two 
Options Development Phase. 

Programmatic Considerations 

A. IOC Cost 

B. Life Cycle Cost 

C. Schedule Impact 

Performance Parameters 

A. Visual Data Assimilation 

B. Information Content 

C. Contrast Ratio. 

Commonality Considerations 
A. Applications 

Risk Assessment 

A. Technology State-of-the-Art 

B. Availability 
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2. 0.2. 2 Color Encoding vs. Monochrome Display Weighting Factors 

The following lists each weighting factor associated with each selec- 
tion criteria used in the color vs. monochrome display trade study. 
These weighting factors were determined by a panel of Sperry space 
station system personnel in conjunction with NASA RFP requirements 
emphasis. 

Programmatic Weighting Factors 

A. IOC Cost Weighting Factor = (0.8) 

B. Life Cycle Cost Weighting Factor = (0.8) 

C. Schedule Impact Weighting Factor = (0.3) 

Performance Weighting Factors 

A. Visual Data Assimilation Weighting Factor = (0.4) 

B. Information Content Weighting Factor = (0.4) 

C. Contrast Ratio Weighting Factor = (0.4) 

Commonality Weighting Factors 

A. Application Weighting Factor = (0.4) 

Risk Criteria Weighting Factors 

A. Technology SoA Weighting Factor = (0.3) 

B. Availability Weighting Factor s (0.3) 
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2. 0.2. 3 Color Encoding vs. Monochrome Display Trade Study 

This trade study evaluates the use of color for information display 
against the use of monochrome. Table 2. 0.2. 3 is the actual trade 
study results. Color displays have the advantage with a figure of 
merit of 84.63 against 72.68 for monochrome displays. From Figure 

2. 0.2. 3 it is clear the main drivers for color displays is the visual 
data assimilation, information content, and application selection 
criteria. 


Figure 2. 0.2. 3 is a bar graph representation of the data in Table 

2. 0.2. 3. By visually scanning this figure it is immediately evident 
that the main drivers for color display information are the visual 
data assimilation, information content, and application selection 
criteria. Programmatic considerations tend to be slightly better for 

monochrome displays. This is not surprising since older, well 
established, technologies will always have lower cost, less schedule 
constraints and etc. 
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2.0.3 INPUT CONTROLS SELECTION 


2. 0.3.1 Input Controls Selection Criteria 

The following lists each selection criteria that will be used in the 
input controls trade study. The selection criteria is divided into 
eight generic categories; programmatic considerations, performance 
parameters, commonality considerations, risk assessment, maintain- 
ability, user friendly reliability, and safety. These selection 
criteria are based on requirements and program goals set forth in 
the NASA RFP. Trade unique criteria were determined by independent 
technology research and defined in the Task Two Option Development 
Phase. 

Programmatic Considerations 

A. IOC Cost 

B. Life Cycle Cost 

C. Schedule Impact 

Performance Parameters 

A. Positioning 

B. Speed 

C. Portability 

D. Ergonomics 

E. Volume 

F. Power 

Commonality Considerations 
A. Application 
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Risk Assessment 


A. Technology State-of-the-Art 

B. Producibility/Availability 

Maintainability 

A. Repairability 

B. Replaceability 


User Friendly 

A. Response Time 


Reliability 

A. Failure Rates 

Safety 

A. Failure Modes 

B. Radiation Tolerance 
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2. 0.3. 2 Input Controls Weighting Factor 

The following lists each weighting factor associated with each 
selection criteria. These weighting factors were determined by a 
panel of Sperry space station personnel in conjunction with NASA 
RFP requirements emphasis. 

Programmatic Weighting Factors 

A. IOC Cost Weighting Factor s (0.8) 

B. Life Cycle Cost Weighting Factor = (0.8) 

C. Schedule Impact Weighting Factor = (0.3) 

Performance Weighting Factors 

A. Positioning Weighting Factor s (0.4) 

B. Speed Weighting Factor = (0.4) 

C. Portability Weighting Factor = (0.4) 

D. Ergonomics Weighting Factor (0.4) 

E. Volume Weighting Factor = (0.4) 

F. Power Weighting Factor = (0.4) 

Commonality Weighting Factors 

A. Application Weighting Factor = (0.4) 

Risk Weighting Factors 

A. Technology S.A. Weighting Factor = (0.3) 

B. Producibility/Availability Weighting Factor = (0.3) 
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Maintainability Weighting Factors 

A. Repairability Weighting Factor = (0.5) 

B. Replaceability Weighting Factor = (0.5) 

User Friendly Weighting Factors 

A. Response Time Weighting Factor = (0.4) 

Reliability Weighting Factors 

A. Failure Rates Weighting Factor = (0.5) 

Safety Weighting Factors 

A. Failure Modes Weighting Factor = (1.0) 

B. Radiation Tolerance Weighting Factor = (0.7) 


14-32 



2. 0.3. 3 Input Controls Trade Study 

This trade study evaluates the use and desirability of current input 
control types for use in the Space Station Crew Workstation. These 
input controls were selected and described in previous sections of 
this study, i.e., Task Two, options phase. The options selected were; 
Keyboard 
Touch Panel 
Joystick 
Light Pen 
Graphics Tablet 
Mouse 
Trackball 
Voice 

Table 2.0. 3. 3 is the trade study results. The choice of a keyboard, 
touch panel, joystick, mouse, light pen or trackball or combination 
thereof would all be appropriate. The graphics tablet has deficiencies 
in the area of size, and voice in the area of technology State-of-the- 
Art. Either would not be desirable due to insufficiencies in these 
areas. 

Table 2. 0.3. 3 is the actual trade study results. The following lists 
the order of preference, and the total dot product of the weighting 
factor vector and the trade parameter vector, for the input controls 
media options. 
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1. Keyboard - 96.80 

2. Trackball - 96.40 

3. Joystick - 94.50 

4. Light Pen - 94.40 

5. Touch Panel - 94.15 

j 

6. Mouse - 88.70 

7. Graphics Tablet - 82.30 

8. Voice - 72.57 

A "figure of merit" is also calculated indicating the percentage of 
satisfying all selection criteria. These are as follows: 

1. Keyboard - 93.81 

2. Trackball - 93.59 

3. Joystick - 91.75 

4. Light Pen - 91.65 

5. Touch Panel - 91.41 

6. Mouse - 86.12 

7. Graphics Tablet - 79.90 

8. Voice - 72.57 

The keyboard and trackball are the leading contenders for input control 
devices for the space station. In reality a keyboard and another input 
control device will probably be used. The trackball, joystic, light 
pen, touch panel and mouse are all candidates. Although the trackball 
is the preferred device, any of the above have potential for use on 
the space station. 

For ease in interpreting the trade study, parameters in Table 2. 0.3. 3 

refer to the bar graph in Figure 2.0. 3.3. 
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Figure 2. 0.3. 3 (cont.) 
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Figure 2. 0.3. 3 (cont.) 
Input Controls Trade Study 


0i 



5 ■ 6 

6 

S * 8 
8 

fi * £. 
L 

S ’ 9 
9 

S ' S 
fi 

S "fr 

S • 8 
8 

S ‘ 8 
8 

S * T 
T 

fi -o 
o 


14-40 


A 

<r 

K 


Relative Weighting # Weighting Factor 




2.0.4 CAUTION AND WARNING SYSTEM SELECTION 


2. 0.4. I Caution and Warning Selection Criteria 

The following lists each selection criteria that will be used in the 
caution and warning trade study. The selection criteria is divided 
into six generic categories; programmatic considerations, performance 
parameters, risk assessment, growth and evolution, safety, and user 
friendly. These selection criteria are based on requirements and 
program goals set forth in the NASA RFP. Trade unique criteria were 
determined by independent technology research and defined in the Task 
Two Options Development Phase. 

Programmatic Considerations 

A. IOC Cost 

B. Life Cycle Cost 

C. Schedule Impact 

Performance Parameters 

A. Power 

B. Volume 

C. Alarm Recognition 

D. Controllability 

E. Alerts 

F . Ergonomics 

Risk Assessment 

A. Technology State-of-the-Art 

B. Availability 
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Growth and Evolution 


A. Growth Capability 


Safety 

A. Failure Modes 


User Friendly 

A. Crew Performance 
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2. 0.4. 2 Caution and Warning Weighting Criteria 

The following lists each weighting factor associated with each selection 


criteria used in the caution and warning trade study. 

Programmatic Weighting Factors 

A. IOC Cost Weighting Factor - (0.8) 

B. Life Cycle Cost Weighting Factor = (0.8) 

C. Schedule Impact Weighting Factor = (0.3) 

Performance Weighting Factors 

A. Power Weighting Factor = (0.6) 

B. Volume Weighting Factor - (0.6) 

C. Alarm Recognition Weighting Factor = (1.0) 

D. Controllability Weighting Factor = (0.7) 

E. Alerts Weighting Factor = (0.7) 

F. Ergonomics Weighting Factor = (0.4) 

Risk Assessment 

A. Technology State-of-the-Art Weighting Factor = (0.3) 

B. Availability Weighting Factor = (0.3) 

Growth and Evolution 

A. Growth Capability Weighting Factor = (0.6) 

Safety 

A. Failure Modes Weighting Factor = (1.0) 

User Friendly 

A. Crew Performance Weighting Factor = (0.4) 


m3 





2. 0,4. 3 Caution and Warning Trade Study 


This trade study evaluates the use and desirability of a distributed 
or integrated caution and warning system for use on the NASA Space 
Station. The options and characteristics were developed in the Task 
Two Options Development Phase. 

It is quite clear that an integrated caution and warning system is the 
overall preferred system with a figure of merit of 94.59. The 
distributed caution and warning system obtained a figure of merit of 
65.06 or 29.53 points below the integrated caution and warning system. 
This result is a reflection of current problems encountered in cur- 
rent distributed avionic caution and warning systems. 

Table 2. 0.4. 3 is an overall bar chart graph of the trade study results. 
It is easily seen that the main drivers in choosing an integrated 
system are: alarm recognition, controllability and failure modes. 

These areas are also areas of concern in todays avionics caution and 
warning systems. 

In todayfe distributed caution and warning systems alarm recognition is 
a problem due to the proliferation of alerts inhibiting the ability to 
correlate the alarm to a specific problem area. Distributed systems 
also prevent the categorizing and prioritizing alerts; an extremely 
important task during periods of high workload. During this period 
of high workload non-critical alerts may not be inhibited or con- 
trollable in a distributed system, leading to a saturating of crew 
members processing capabilities. This may lead to dangerous failure 
modes by superfluous or misleading error alerts or alarms. 
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MftSS STORAGE TRADE STUDY 


1. Reason For Trade Study 

(lass storage devices will be used extensively by the SSDS for both on-board 
and ground elements. This trade study will identify preferred options and 
configurations for the specific application areas that are expected to drive 
the system design and/or stress the available technology. 

2. Background 

The Space Station Program will handle, process, and store unprecedented 
quantities of data. This will require innovative concepts that address a wide 
range of data storage requirements from short-term buffering to long term 
archival. The type of data will also vary significantly and includes the 
following: 

Software 

Manuals 

Command Procedures 
Level 0 Data 

Communication (voice, video) 

Engineering Data 
Real Time Data 
Buffered Data 
Trend Data 

Diagnostics Support Data 
Etc. 

While mass storage devices will be used extensively throughout the SSDS, 
commercially available products will satisfy many of the program needs. 
However, specific applications areas have been identified that are expected to 
be design/technology drivers. In these areas a more detailed analysis is 
required to identify preferred devices and configurations. Since these 
applications are likely to have a wide variation in requirements and 
architectural needs, it is likely that different technologies may be 
appropriate for the different applications. 


PAGE BLV4X SOT FILMED 
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The drivers for these applications are requirements (documented in the Task 1 
report), derived requirements, and design characteristics. The key 
application areas to be addressed by this trade study are: 

A. Buffering of delayable payload data both in space and on the ground 

B. Short term archiving of customer data 

C. On-board space station data base 

Key buffering design characteristics developed from simulations of a 
preliminary end-to-end concept and the LaRC data base as modified by the Moods 
Hole update are presented in Table 1. A graphic representation of the 
buffering loads driven by mission needs and communication constraints is shown 
in figure 2. Table 1 shows that the buffering requirements are separated into 
three functional areas, on-board space station, on-board polar-orbiting 
platform (POP), and data handling center buffers. P0P(1) simulation results 
are used as they represent the worst case POP design characteristics . Final 
design characteristics for each functional area will be a function of system 
design and will be derived during this study and in conjunction with evolving 
system definition concepts. 



SPACE 

POLAR-ORBIT 

DATA HANDLING 


STATION 

PLATFORM 

CENTER 

CAPACITY : 

2 X 10 11 BITS 

5.1 X 10 11 BITS 

10 12 BITS 

TRANSFER RATE: 

300 MBITS/SEC 

300 MBITS/SEC 

IN: 900 MBITS/SEC 


-6 

-6 

-6 

BIT ERROR RATE: 

< 10 

< 10 

<10 

PHYSICALS: 

SPACE FLIGHT 

SPACE FLIGHT 

NONE 


CONSTRAINED 

CONSTRAINED 


RAD HARDNESS 




TOTAL DOSE: 

230 RADS/YEAR 

2K-25K RADS/YEAR 

NONE 

RELIABILITY 




MAINTAINABILITY : 

MAN AVAILABLE 

SPECIAL MISSION 

MAN AVAILABLE 


Table 1: Design characteristics for critical SSDS buffers 






Requirements for short term archiving were developed by integrating the 
mission set average data rate, for both IOC and growth, over the appropriate 
time periods. The results of this mission set analysis are given below and 
range from the IOC amount to the growth amount. 

A. 12 hour on-line storage 

5-8 X 10 12 bits capacity 
60 seconds access time 

Average transfer rate of 110-179 Mbits/sec 

B. 7 day off-line storage 

7-10 X 10 13 bits capacity 

Less than 24 hours access time 

Average transfer rate of 110-179 nbits/sec 

Storage of manuals and procedures, software, scheduling information, and 
storage for customer data are a few of the many types of data the on-board 
space station data base must store. As a whole, the mass storage system for 
the on-board data base should provide fast access to the numerous kinds of 
data. An analysis of the functions presented in Task 1 and the mission set 
indicate that the on-board data base will have the following requirements 

9 

Storage capacity of 2 X 10 bits 
Access time of 40 milliseconds 
Peak transfer rate of 10 (Ibits/sec 

Results from the following trade studies will also have an impact on the mass 
storage trade study: 

A. End-to end networking 

B. On-board local area networking 

C. Distributed data base management 

D. Space communications 

The results from the above trade studies will directly affect the end-to-end 
model used in the simulations that determine design characteristics . As the 
trade studies progress, the model will be refined to reflect results from 
other trade areas in order to obtain a consistent model. 
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3. Issues 


The issues presented below are important because they will dictate to some 
extent which technologies are used for mass storage in the SSDS. This trade 
study will attempt to resolve these issues and determine which technologies 
are best suited for the SSDS. 

A. Figure 3 depicts the relationship between currently available mass 
storage devices and the various SSDS applications. What is the risk 
that present devices or new technology can evolve to meet the more 
demanding design characteristics imposed by these SSDS applications? 

B. Can a common buffer capability be developed for space station and 
polar-orbit platforms? 

C. What kind of on-board buffering configurations are needed to handle: 

1. Merging of data from multiple sources? 

2. High peak rates of up to 500 Mbits/sec? 

D. Which technology will provide the more cost effective media for the 
large quantity of data storage needed by the short term archiving 
application? 

E. Which technology can provide the fast access time needed by the 
on-board data base and also provide the necessary capacity? 

4. Trade Study Criteria 

The mass storage options/configurations for each application will be evaluated 
using the criteria presented in table 4. Each criterion is weighted according 
to its overall relative importance in each application. For example, 
environment and reliability will be given higher weights in the polar-orbit 
application than in the space station application because of the man 
availability on the space station. After evaluating the various options to 
see how well they meet the design characteristics and requirements for each 
application they will be ranked from one to ten for each criterion. That 
ranking will be multiplied times the weight given to that particular 
criterion. Summing the results for each option gives a figure of merit that 
should indicate which option is best suited for use in the particular 
application being studied. 15.7 
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Figure 3. Relationship of Present Technology to Various SSDS Applications 
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5. Expected Results 


By following the outlined methodology, the preferred mass storage device and, 
if applicable, configuration can be found for each of the application areas. 
Also, through the trade study process the issues presented in Section 3 should 
be resolved or result in the identification of technology deficiencies that 
need to be addressed by the Space Station Program. 

6. Methodology 

The basic approach that was taken for the trades on buffering applications 
consisted of the following: 

A. Fully characterize the options to be traded. This was done and documented 
as part of Task 2. 

B. Derive the design characteristics for each buffering application. As the 
mission model is updated, and certain end-to-end options chosen, a 
simulation of the end-to-end model was done to further refine the design 
characteristics for each buffering application. The buffering design 
characteristics are presented in Table 1. 

C. Develop candidate configurations. Buffering of delayable data is a complex 
function which can be implemented in a variety of ways, thus each buffering 
application needs to be looked upon as a system configuration rather than 
simple device options. To do this, various configurations were developed 
that use one or more of the options (that is, different configurations may 
be required to make the most efficient use of a given device technology). 

A by-product of this step are design concepts that can be used in system 
definition. 

D. The configurations were evaluated and ranked according to the set of 
criteria presented in Section 4. The result of the ranking was a figure of 
merit that indicated which technologies were best suited to meet the 
buffering design characteristics. 
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E. Perform a sensitivity analysis. After ranking the options, a sensitivity 
analysis was done to identify tradeoffs that can be made that influence the 
choice of option/configuration and design characteristics. The sensitivity 
analysis also identified major discriminators between the options and 
supports technology recommendations. 

The approach that was taken for the short term archiving trade consists of the 

following: 

A. Fully characterize the options to be traded. This has was done and 
documented as part of Task 2. 

B. Derive the requirement for customer data archiving. This was done by 
simply integrating the mission set data rates over the appropriate time 
period. The requirement was refined as the mission set was modified. 

C. The options were evaluated and ranked according to the set of criteria 
presented in Section 4. The result of the ranking was a figure of merit 
that indicated which technologies were best suited to meet the short term 
archiving requirement. 

D. Perform a sensitivity analysis. After ranking the options, a sensitivity 
analysis was done to identify tradeoffs that can be made that influence the 
choice of options and design characteristics . The sensitivity analysis 
also identified major discriminators between the options and supports 
technology recommendations. 

The approach that will be taken for the on-board data base trade consists of 

the following: 

A. Fully characterize the options to be traded. This was done and documented 
as part of Task 2. 

B. Derive the design characteristics for driving on-board data base 
applications. This depended on the results from the on-board system 
definition activity. Preliminary characteristics have been developed and 
are presented in Section 2. 
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C. The options were evaluated and ranked according to the set of criteria 
presented in Section 4. The result of the ranking was a figure of merit 
that indicated which technologies were best suited to meet the on-board DMS 
mass store requirement. 

D. Perform a sensitivity analysis. After ranking the options, a .sensitivity 
analysis was done to identify tradeoffs that can be made that influence the 
choice of options and design characteristics . The sensitivity analysis 
also identified major discriminators between the options and supports 
technology recommendations. 

7. Trade Study Discussion and Results 

On-Board Space Station Communication Data Buffer 

Space station missions can be divided into two categories; high data rate 
missions and low data rate missions. For the purpose of this trade study, 
high data rate missions are those with a peak data rate in excess of 10 
Mbits/sec. The low data rate missions are those with a peak data rate less 
than or equal to 10 nbits/sec. In the on-board space station payload data 
communication buffer model shown in figure 5 it can be seen that there are two 
data buffers used to buffer the communication data. These two buffers are the 
high rate data buffer and the payload local area network (PLAN) communication 
data buffer. 
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Figure 5. On-Board Space Station Payload Data Communication Buffer Model 
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High Rate Data Buffer 


If the communication resource is not available the high rate data must be 
buffered in the high rate data buffer. This buffer is a resource that must be 
scheduled in advance. A simulation of the end-to-end model indicates the 
design characteristics for the high rate data buffer to be: 


Capacity: 
Transfer Rate: 

BER: 

Environment: 
Size,Wt. ,Pwr. : 
Shock & Vib. : 
Radiation : 


2 X 10 ll Bits 
In: 300 Mbits/sec 

41 

Out: 600 Mbits/ sec 



Inside space station, 28.5° Orbit For |10 Years 
TBO, Space Flight Constrained 
Non-operating Launch Survivable 
230 Rads/year 


* Assuming two KSA channels can be available 


The device options for the high rate data buffer are: 

1. Magnetic Tape 

2. Magnetic Disk 

3. Optical Disk 

4. Magnetic Bubble 


Magnetic Tape 

The high rate buffer design characteristics could be met by one magnetic tape 
device, or several magnetic tape devices in the proper configuration. 

Although magnetic tape is serial access it is still quite versatile. Data can 
be recorded at one rate and played back at another. The media can be removed 
from the device and transported to the ground via STS when extra data security 
is needed or sufficent TDRSS bandwidth is not available. Magnetic tape is 
also a mature mass storage device that has been used in space missions since 
the start of the space program. 
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Even though the design characteristics for the high rate buffer can be 
implemented using only one magnetic tape device it is more desirable to use an 
arrangement consisting of three magnetic tape devices. The advantages of the 
three device arrangement over a single device include: 

1. Simultaneous record and playback 

2. Redundancy that improves system reliability 

3. Less Sophisticated device (don't have to push the technology as hard) 

4. Modularity that enhances growth capability 

The three device high rate buffer system would have the following 
characteristics : 


Capacity : 

2 X 10** Bits/system 
6.6 X 10*° Bits/device 

Transfer Rate: 

300 Mbits/sec/device 

Device Type: 

Rotary 

BER: 

10 ^/device 

Rad Hardness 

Good 

Volume 

3 

10,000 Inches /system 

Weight 

300 Lbs/system 

Power 

500 Watts Peak/system 

Recurring Cost 

$750, 000/system 

Risk 

Low 

Reliability 

Proven High Reliability 

Maintainability 

Moderate Maintenance Required 


* All costs are relative for similar flight-qualified devices on the 

assumption that space qualification cost is a constant factor times the 
device cost. This was done so that all the options can be compared at the 
same level. 

The limitations of using magnetic tape include: 

1. Magnetic tape is serial access 

2. Future technology insertion of a random access device is constrained 

3. Moving parts that are less reliable than that of solid state devices 
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Magnetic Disk 


A high rate data buffer designed using the projected space qualified magnetic 
disk devices would have the following characteristics: 


Capacity : 

Number of devices: 
Transfer Rate: 

BER 


2 X 10** Bits/system 
3X10** Bits/device 
67 

20 Mbits/sec/device 


Peak power: 

# 

Recurring Cost : 
Volume: 

Weight: 

Development Risk: 
Radiation Hardness: 
Reliability : 
Maintenance: 


13,400 watts/system, 200 Watts/device 
$751, 212/system 

3 

40,200 inches /system 
3350 lbs/system 
Medium 
Good 

Consistent with a device with moving parts 
Extensive 


X Cost does not include space qualification cost 

A single magnetic disk device cannot meet the transfer rate design 
characteristic . It is questionable that a method of paralleling the devices 
together to achieve the transfer rate design characteristic can be devised. 
Also, the weight and power characteristics quickly rule out the use of 
magnetic disk as the high rate data buffer. 

Eraseable Optical Disk 

Eraseable optical disk is a relativly new technology that has most of the 
characteristics that would make it a candidate for the high rate data buffer. 
Optical disk devices have high capacity and fast data transfer rates. 

Currently they are non-erasable, which would make them unsuitable for use in 
the high data turnover application of data buffering. Techniques have been 
developed and demonstrated that would give the optical disk eraseability . RCA 
is one company that has been doing extensive work in the optical disk field. 
They currently have two non-eraseable optical disk jukeboxes installations: 
one at Langley Research Center and the other at Rome Air Development Center. 
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RCA has proposed an "Optical Disk Buffer" that would employ an eraseable 
magneto-optic technique to produce a buffer that would have a large capacity 
and fast data transfer rate in a relativly small package. The "Optical Disk 
Buffer" would have the following characteristics : 


Capacity : 

Transfer Rate: 
Power: 

Volume: 

Weight: 

# 

Recurring Cost : 

Radiation Hardness: 
Risk: 

Reliability : 
Maintainabi 1 ity : 


12 

10 Bits 
1000 Mbits/sec 
500 Watts Average 
61,000 Inches^ 

700 lbs 

TBD (A Price model indicates $10,000,000 
for a space qualified device) 

TBD (Should be good) 

Medium High 

Consistent with a device with moving parts 
TBD 


* Price does include space qualification cost 


Because eraseable optical disk is a new technology the development risk is 
much higher than that of magnetic tape, but the technology for the "Optical 
Disk Buffer" has been demonstrated in the lab, and with the proper funding the 
device can be developed and ready for use in the 1992 space station. 
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Bubble Memory 


A high rate data buffer designed using magnetic bubble memory would have the 
following characteristics : 


Capacity : 

Device Count: 

Transfer Rate: 

Number of Devices Needed To 
Achieve Design Characteristic 
Transfer Rate: 

BER: 

Peak Power: 

Weight: 

Volume: 

* 

Cost : 

Development Risk: 

Radiation Hardness: 

Reliability : 

Maintainability 


2 X 10 11 Bits/system 
16X10® Bits/device 
12,500 

400 Kbits/sec/device 


750 

lo " 14 

8 watts/device 

^ 6000 watt at 300 Mbits /sec 
2,500 lbs/system 

3 

75,000 Inches /system 
$1,250, 000/sy stem 
Medium 

TBD (depends on current development 
efforts) 

Very Good (solid state device) 

Moderate, modular replacement of devices. 


As with magnetic disk, it would take too many of the magnetic bubble devices 
to construct the high rate data buffer. The system cost, weight, volume, and 
power would be far too much. 


On-Board Space Station High Rate Buffer Results 

After assessing the various options to see how well they would fit into the 
space station high rate buffer the options were ranked from one to ten (ten 
being best) for each criterion. Table 6 presents the results of the 
rankings. Magnetic disk and magnetic bubble are not qualified for use as the 
space station high rate buffer because of poor physical characteristics . This 
leaves magnetic tape and optical disk as candidates for the space station high 
rate buffer. 
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| OPTIONS 





TABLE 6: ON-BOARD SPACE STATION HIGH RATE BUFFER 


15-19 







The most significant discriminators between magnetic tape and optical disk are 

1. Development Risk 

2. Special Considerations 

Magnetic tape is a mature mass storage device that has been used since the 
start of the space program. Today it is still used almost exclusively for 
spacebom mass data storage. If magnetic tape is selected to be used as the 
space station high rate data buffer the major development effort will be in 
pushing the data rate up to 300 Mbits/sec. This data rate can be met with the 
longitudinal recording method at the expense of power and weight, or the data 
rate can be met with the newer, not as mature, rotary recording method. 

Random access and a capability to simultaneously record and playback several 
channels of high rate data are the optical disk's main advantages. This 
eliminates bit reversal problems asssociated with some magnetic tape 
techniques. The development risk of an optical disk high rate buffer is 
high. The major techniques involved with the magneto— optic technique that 
this buffer would use have already been demonstrated, but a lack of funding 
has slowed down the development effort. If proper funding is supplied up 
front, the development risk for the optical disk buffer could go down 
considerably. Some of the potential payoffs for doing this include: 

1. A buffering device with random access 

2. No need to incur the extra cost of inserting the optical disk 
technology at a later date. 

3. Improved performance of the buffering system over magnetic tape. 
Space Station High Rate Buffer Recommendations 

It is recommended that advanced development efforts be focused on eraseable 
optical disk technology for this buffering application to reduce the perceived 
risk associated with this option. With sufficient emphasis this technology 
could be demonstrated and considered for the IOC configuration. If such 
emphasis is not provided, magnetic tape provides a mature base for IOC, 
however, eraseable optical disk development should continue for insertion into 
the growth space station because of the benefits it can provide. 
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Space Station Payload Local Area Network (PLAN) Communication Data Buffer 


An estimate of the design characteristics for the PLAN communication data 

buffer was obtained by buffering the total average data rate of all the low 

rate missions for one orbit. The sum of all the IOC low rate missions, 

including the co-orbiting platform mission, is 2.175 nbits/sec. Integrating 

g 

that over one 90 minute orbit results in the need to buffer 12 x 10 bits of 
data. The full design characteristics for the PLAN communication data buffer 
are: 


Capacity : 
Transfer Rate: 
BER: 

Environment: 
Size, Wt., Pwr. : 
Shock & Vib. : 
Radiation: 


12 X 10 9 bits 
10 Mbits/second 
< 10 -6 

Inside space station, 28.5° orbit for 
TBD, space flight constrained 
Non-operating launch surviable 
230 Rads/year 


10 years 


The device options for the PLAN communication data buffer are: 

1 . Magnetic Tape 

2. Magnetic Disk 

3. Optical Disk 

4 . Bubble Memory 
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Magnetic Tape: 


The PLAN communication data buffer can be built with present technology. An 
Odetics DDS-6000 Spacelab magnetic tape recorder is one example of a space 
qualified device that could meet the design characteristics of the PLAN 
communication data buffer. The specifications for the DDS-6000 are: 


Capacity: 
Transfer Rate: 
BER: 

Device Type: 

Rad Hardness: 
Shock & Vib. : 
Weight: 

Volume: 

Power: 

Recurring Cost: 
Development Risk: 
Reliability : 
Maintainabi 1 ity : 


3. 84 X 10 10 bits 
32 Mbits/second 
ID" 6 

Longitudinal 

Good 

Space Qualified 
105 lbs 

3 

4000 inches 
174 Watts Peak 
$1,500,000* 

Low 

Good 

Moderate maintenance required 


X Cost for Space qualified device only 


The device presented above has good performance figures, but because it is a 
serial access device, the buffer would have to operate as a first in, first 
out type of device thu3 preventing an implementation of a priority 
transmission scheme. 
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Magnetic Disk 


A PLAN communication data buffer designed with projected magnetic disk 
capabilities would have the following characteristics: 


Capacity: 

12 X 10 9 bits/system 

Transfer Rate: 

20 Mbits/second/system 

# of Devices: 

4 


-10 

BER 

< 10 

Volume : 

3 

2400 inches /system 

Weight: 

200 lbs/system 

Power: 

800 Watts Peak/system 

Recurring Cost: 

$44, 400/system 

Development Risk 

Medium 

Reliability : 

Consistent with a non-solid state device 

Maintainability : 

Moderate maintenance required 


The projected magnetic disk device has good performance figures, but it also 
has a high power requirement. 

Optical Disk 


If development of the "Optical Disk Buffer" proceeds as recommended in the 
section on the on-board space station high rate buffer then a smaller capacity 
optical buffer could be developed out of the same program for use as the PLAN 
communication data buffer. The characteristics of such a buffer could be: 


Capacity: 

Transfer Rate: • 

Power: 

Volume: 

Weight: 

* 

Cost : 

Rad Hardness: 
Development Risk: 
Reliability : 
Maintainability : 


8 X 10 10 bits 
100 Mbits/sec 
200 Watts average 

3 

5100 inches 
200 lbs 

TBD (rough order of magnitude: $1,000,000) 
TBD (good) 

Medium high 

Consistent with a device with moving parts 
TBD 


* Price does include space qualification cost. 
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Because eraseable optical disk is a new technology, the development risk is 
much higher than that of magnetic tape, but the technology for the "Optical 
Disk Buffer" has been demonstrated in the lab, and with proper funding the 
device can be developed and ready for use in the 1992 space station. 


Bubble Memory 


A PLAN communication data buffer designed using magnetic bubble would have the 
following characteristics : 


Capacity: 12 X 10 9 bits 

Transfer Rate: 10 Mbits/second 

Number of devices needed to 
achieve transfer rate: 25 

Power: 8 Matts/device Peak 

> 200 Matts/system at 10 Mbits/sec 


Weight: 

Volume: 

* 

Recurring Cost : 
Development Risk: 
Rad Hardness: 
Reliability : 
Maintainabi 1 ity : 


150 lbs 

3 

4500 inches 

$75,000 

Medium 

TBD (depends on current development effort) 
Very good (solid state device) 

Moderate, Modular replacement of devices 


* does not include space qualification cost 

Bubble memory has good characteristics in all but one area, radiation 
hardness. Current bubble memory support electronics use a 
Metal-Oxide-Semiconductor technology that is not radiation hard. The USAF 
currently has a development program to produce a space qualified chip set that 
may have potential application in space. 


Space Station PLAN Communication Data Buffer Results 


After assessing the various options to see how well they would fit into the 
space station PLAN communicaion data buffer, the options wer’e ranked from one 
to ten (ten being best) for each criterion. Table 7 presents the results of 
the ranking. 
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All of the candidate options are capable of serving as the space station PLAN 
communication data buffer. The major discriminators between the options are: 

1 . Cost 

2. Development Risk 

3. Power Requirements 

4. Performance 

5. Special Considerations 

Magnetic tape is the most mature of the options, thus it has a lower cost and 
development risk. Sequential access is a major drawback to the use of 
magnetic tape as a data buffer. Because of the sequential access 
characteristic a priority transmission of buffered data scheme is not possable. 

Magnetic disk has adequate performance and growth potential, but unless unless 
its power requirements can be lowered it should not be considered as an option 
for the PLAN communication buffer. 

Optical disk has very good performance figures. It offers excess capacity on 
the order of 7.6 times the desired design characteristic, thus giving plenty 
of capacity for use in the growth configuration. A special consideration is 
the random access characteristic of optical disk thus providing improved 
performance and the ability to implement a scheme to have priority 
transmission of buffered data. 

Eraseable optical disk has a high development risk because it is an emerging 
technology, but the technology has been demonstrated in the laboratory with 
promising results. The development risk and cost will be reduced if the PLAN 
communictaion data buffer and the space station high rate data buffer share 
the same optical disk development effort. By sharing the development effort 
the risk could be significantly reduced because of the increased funding that 
could be available. This shared development effort can also lead to device 
commonality that would further reduce overall costs. 
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TABLE 7: ON-BOARD SPACE STATION PLAN COMMUNICATION DATA BUFFER 
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Bubble memory has a good figure of merit, but it falls short in the areas of 
performance and radiation hardness. A current Air Force development program 
might give the bubble memory potential for use this applications. 

Space Station PLAN Communication Data Buffer Recommendations 

It is recommended that advanced development efforts be focused on eraseable 
optical disk technology for this buffering application to reduce the perceived 
risk associated with this option. Furthermore, this development effort should 
be part of the same development effort that is recommended for the space 
station high rate data buffer. This will reduce overall development cost and 
increase optical disk development funding that would tend to further reduce 
the eraseable optical disk development risk. 

If the eraseable optical disk development does not proceed as recommended, 
magnetic tape can be brought into the IOC configuration at a later date 
because of it's maturity. However, optical disk development should continue 
for insertion into the growth space station because of the benefits it can 
provide. 
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On-Board Polar-Orbit Platform (POP) Communication Data Buffer 


A simulation of the end-to-end model indicates the design characteristics for 
the worst case POP data buffer to be: 


Capacity : 
Transfer Rate: 
BER: 

Environment: 
Size,Wt. , Pwr. : 
Shock & Vib. : 
Radiation: 


5.1 X 10 U Bits 
300 Mbits/sec 
< 10 -6 

On POP 90° Orbit For | 10 Years 
TBD, Space Flight Constrained 
Non-operating Launch Survivable 
2K - 25k Rads/year 


The device options for the POP data buffer include: 


1 . Magnetic Tape 

2. Magnetic Disk 

3. Optical Disk 

4. Magnetic Bubble 

Magnetic Tape 

The POP buffer design characteristics could be met by one magnetic tape 
device, or several magnetic tape devices in the proper configuration. 

Although magnetic tape is serial access it is still quite versatile. Data can 
be recorded at one rate and played back at another. Magnetic tape is also a 
mature mass storage device that has been used in space missions since the 
start of the space program. 

Even though the design characteristics for the POP buffer can be implemented 
using only one magnetic tape device it is more desirable to use an arrangement 
consisting of three magnetic tape devices. The advantages of the three device 
arrangement over a single device include: 
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1. Simultaneous record and playback 

2. Redundancy that improves system reliability 

3. Less Sophisticated device (don't have to push the technology as hard) 

4. nodularity that enhances growth capability 

The three device POP buffer would have the following characteristics : 


Capacity: 

5.1 X 10** Bits/system 
1.7 X 10** Bits/device 

Transfer Rate: 

300 Mbits/sec/device 

Device Type: 

Rotary 

BER: 

10 /device 

Rad Hardness 

Good 

Volume 

3 

10,000 Inches /system 

Weight 

300 Lbs/system 

Power 

500 Watts Peak/system 

Recurring Cost 

$750, 000/ system 

Risk 

Low 

Reliability 

Proven High Reliability 

Maintainability 

Moderate Maintenance Required 


* Most costs are for similar flight-qualified devices on the assumption that 
space qualification cost is a constant factor times the device cost. This 
was done so that all the options can be compared at the same level. 

The limitations of using magnetic tape include: 

1. Magnetic tape is serial access 

2. Future technology insertion of a random access device 

3. Moving parts that are less reliable than that of solid state devices 
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Magnetic Disk 


A POP data buffer designed using the projected space qualified magnetic disk 
device would have the following characteristics : 


Capacity : 

Number of devices: 


5.1 X 10 11 Bits/system 
3X10 8 Bits/device 
170 


Transfer Rate: 20 Mbits/sec/device 

BER 10 -8 


Peak power: 

# 

Recurring Cost : 
Volume: 

Weight: 

Development Risk: 
Radiation Hardness: 
Reliability : 
Maintenance : 


34.000 watts/system, 200 Watts/device 
$1 , 906 , 000/ sy stem 

3 

102.000 inches /system 
8500 lbs/system 
Medium 

Good 

Consistent with a device with moving parts 
Extensive 


* Cost does not include space qualification cost 


A single magnetic disk device cannot meet the transfer rate design 
characteristic. It i3 questionable that a method of paralleling the devices 
together to achieve the transfer rate design characteristic can be devised. 
Also, the weight and power characteristics quickly rule out the use of 
magnetic disk as the POP data buffer. 


Eraseable Optical Disk 

Eraseable optical disk is a relativly new technology that has most of the 
characteristics that would make it a candidate for the POP data buffer. 

Optical disk devices have high capacity and fast data transfer rates. 

Currently they are non-erasable, which would make them unsuitable for use in 
the high data turnover application of data buffering, but techniques have been 
developed and demonstrated that would give the optical disk eraseability . RCA 
is one company that has been doing extensive work in the optical disk field. 
They currently have two optical disk jukeboxes installations; one at Langley 
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Research Center and the other at Rome Air Development Center. RCA has 
proposed an "Optical Disk Buffer" that would employ a magneto-optic technique 
to produce a buffer that would have a large capacity and fast data transfer 
rate in a relativly small package. The "Optical Disk Buffer" would have the 
following characteristics : 


Capacity : 

Transfer Rate: 
Power: 

Volume: 

Weight: 

Cost: 

Radiation Hardness: 
Risk : 

Reliability : 
Maintainability : 


12 

10 A * Bits 
1000 Mbits/sec 
500 Watts Average 

3 

61,000 Inches 
700 lbs 

TBD (A Price model indicates $10,000,000 
for a space qualified device) 

TBD (Should be good) 

Medium High 

Consistent with a device with moving parts 
TBD 


Because eraseable optical disk is a new technology the development risk is 
much higher than that of magnetic tape, but the technology for the "Optical 
Disk Buffer" has been demonstrated in the lab, and with the proper funding the 
device can be developed and ready for use in the 1992 Space Station Program. 
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Bubble Memory 


A POP data buffer designed using magnetic bubble memory would have the 
following characteristics: 


Capacity : 

Device Count: 

Transfer Rate: 

Number of Devices Needed To 
Achieve Design Characteristic 
Transfer Rate: 

BER: 

Peak Power: 

Weight: 

Volume: 

* 

Cost : 

Development Risk: 

Radiation Hardness : 

Reliability : 

Maintainability 


5.1 X 10** Bits/system 
16X10 6 Bits/device 
31,875 

400 Kbits/sec/device 


750 

IQ" 14 

8 watts/device 

>6000 watt at 300 Mbits/sec 
6375 lbs/system 

3 

191,250 Inches /system 
$3, 187,000/system 
High 

TBD (depends on current development 
efforts) 

Very Good (solid state device) 

Moderate, modular replacement of devices. 


As with magnetic disk, it would take too many of the magnetic bubble devices 
to construct the POP data buffer. The system cost, weight, volume, and power 
would be far too much. 


On-Board POP Communication Data Buffer Results 


After assessing the various options to see how well they would fit into the 
POP communication data buffer the options were ranked from one to ten (ten 
being best) for each criterion. Table 8 presents the results of the ranking. 
Magnetic disk and magnetic bubble are not qualified for use as the POP 
communication data buffer because of poor physical characteristics . This 
leaves magnetic tape and optical disk as candidates for the POP communication 
data buffer. 
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| OPTIONS 


1 CRITERIA WEIGHT | MAGNETIC | MAGNETIC | OPTICAL | MAGNETIC 

1 

1 


|TAPE 

TOTAL | DISK 

TOTAL | DISK 

TOTAL | BUBBLE TOTAL | 

i 

|COST 

1 

1 


1 

1 


1 

1 


1 

1 


1 

j DEVELOPMENT: 

4 | 

10 

40 | 

8 

32 | 

7 

28 | 

9 

36 | 

| RECURRING: 

5 I 

9 

45 j 

8 

40 | 

6 

30 | 

7 

35 | 

j MEDIA: 

1 j 
1 

7 

7 | 
1 

10 

10 | 
i 

8 

8 1 
1 

9 

9 1 

|DEVL. RISK: 

1 

15 | 
1 

10 

1 

150 | 
1 

9 

1 

135 | 
1 

7 

1 

105 | 
1 

8 

120 | 

| GROWTH 

1 

i 


I 

i 


1 

i 


1 

i 



| EXTENDABLE: 

4 i 

9 

36 | 

8 

32 | 

7 

28 | 

10 

40 | 

jlNSERTABLE: 

6 I 
1 

8 

48 j 
1 

10 

60 | 
1 

9 

54 j 
1 

7 

42 j 

| RAM 

1 

1 


1 

1 


1 

1 


1 

1 



j RELIABILITY : 

8 I 

7 

56 | 

8 

64 | 

9 

72 | 

10 

80 | 

I AVAILABILTY : 

5 I 

7 

35 | 

8 

40 j 

10 

50 j 

9 

45 j 

(MAINTAINABILITY: 

2 I 
1 

9 

18 | 
1 

7 

14 | 
1 

8 

16 | 
1 

10 

20 j 

| PHYSICALS 

1 

1 


1 

1 


1 


1 

1 



| WEIGHT: 

6 1 

10 

60 | 

3 

18 | 

8 

48 | 

4 

24 1 

| POWER : 

9 1 

I 

10 

90 | 
1 

4 

36 j 

i 

9 

81 | 
1 

3 

27 j 

| ENVIRONMENT 

1 

1 


1 

1 


1 

1 


I 

1 



|RAD HARDNESS: 

10 | 

9 

90 | 

9 

90 | 

9 

90 | 

6 

60 1 

| SHOCK & VIB: 

5 | 

i 

9 

45 | 

l 

7 

35 | 

I 

8 

40 j 

i 

10 

50 ( 

| PERFORMANCE 

1 


1 

1 


1 

1 


1 

1 



| CAPACITY: 

4 I 

10 

40 | 

6 

24 | 

9 

36 | 

7 

28 | 

(TRANSFER RATE: 

5 | 

9 

45 | 

4 

20 | 

10 

50 j 

6 

30 j 

j BER : 

4 I 

8 

32 1 

9 

36 j 

7 

28 j 

10 

40 j 

| ACCESS TIME: 

2 I 

i 

6 

12 j 

l 

8 

16 j 
1 

10 

20 | 
1 

9 

18 | 

| SPECIAL: 

1 

5 | 

0 

1 

o I 

7 

1 

35 | 

10 

1 

50 | 

6 

30 | 

| TOTALS 

1 

100 ( 


1 

849 | 


i 

737 | 


i 

834 | 


734 | 


TABLE 8: ON-BOARD POLAR-ORBIT PLATFORM COMMUNICATION DATA BUFFER 
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The most significant discriminators between magnetic tape and optical disk are 

1. Development Risk 

2. Special Considerations 

Magnetic tape is a mature mass storage device that has been used since the 
start of the space program. Today it is still used almost exclusively for 
spaceborn mass data storage. If magnetic tape is selected to be used as the 
space station high rate data buffer the major development effort will be in 
pushing the data rate up to 300 Mbits/sec. 

Random access and a capability to simultaneously record and playback several 
channels of high rate data are the optical disk's main advantages. This 
eliminates bit reversal problems asssociated with some magnetic tape 
techniques. The development risk of an optical disk high rate buffer is 
high. The major techniques involved with the magneto-optic technique that 
this buffer would use have already been demonstrated, but a lack of funding 
has slowed down the development effort. If proper funding is supplied up 
front, the development risk for the optical disk buffer could go down 
considerably. Some of the potential payoffs for doing this include: 

1. A buffering device with random access 

2. No need to incur the extra cost of inserting the optical disk 
technology at a later date. 

3. Improved performance of the buffering system over magnetic tape. 
POP Communication Data Buffer Recommendations 


It is recommended that advanced development efforts be focused on eraseable 
optical disk technology for this buffering application to reduce the perceived 
risk associated with this option. Furthermore, this development effort should 
be part of the same development effort that is recommended for the space 
station high rate data buffer. This will reduce overall development cost and 
increase optical disk development funding that would tend to further reduce 
the eraseable optical disk development risk. If the eraseable optical disk 
development does not proceed as recommended, magnetic tape can be brought into 
the IOC configuration at a later date because of it's maturity. However, 
optical disk development should continue for insertion into the growth Space 
Station Program because of the benefits it can provide. 
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Data Handling Center Buffer 


The data handling center buffer will need to buffer data coining from the TDRSS 

KSA communication links at rates up to 900 Mbits/second. A computer 

simulation of the end-to-end model determined that it is necessary to buffer 
12 

10 bits of high rate data. Assuming TDRSS uses three KSA links evenly, a 
separate buffer with a capacity of 3.3 X 10 11 bits and a transfer rate of 
300 Mbits/sec will be allocated for each TDRSS KSA link. Therefore the design 
characteristics for a common TDRSS KSA buffer will be: 

3.3 X 10** bits capacity 
300 Mbits/second transfer rate 
BER < 10' 6 


The options for the data handling center buffer are: 

1. Magnetic Tape 

2. Magnetic Disk 

3. Optical Disk 

Magnetic Tape 

To design the data handling center buffer using magnetic tape would require a 
configuration of three magnetic tape devices per KSA link. One device to 
record, one device to playback, and one device would be in between the two 
operations. The characteristics of such a device should include: 

1. 110 Gbits capacity 

2. Data transfer rate of up to 300 Mbits/second 

3. Variable playback rate. 

It is predicted that such a high performance device can be built and would 
carry a price tag of over 1 million dollars each. In this scheme all data 
would be processed first in first out, thus not allowing any priority level 0 
processing on the ground. Over the full range of criteria magnetic tape 
appears to be a good candidate for the data handling center buffer. 
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Magnetic Disk 


Because of the requirement to record at 300 Mbits/sec magnetic disk might not 
be able to be used as the data handling center buffer. Predicted magnetic 
disk devices will only achieve a transfer rate of around 40 Mbits/sec. The 
only way magnetic disk could be used is if the data is split into manageable 
streams around 40 Mbits/sec. This is possible if real time processing to 
split the data into streams of complete packets is done as the data is 
received from the TDRSS KSA link. To buffer the expected 330 Gbits of data 
would require 10 devices with a capacity of 33 Gbits each. The total cost for 
these 10 device would be approximately 1 million dollars. 

Optical Disk 

The RCA "Optical Disk Buffer" proposed for the on-board space station data 

buffer would also have use in the data handling center buffer application. 

12 

The "Optical Disk Buffer" characteristics of 10 bits capacity and and 

9 

10 bits/sec transfer rate make the "Optical Disk Buffer" an ideal candidate 
for the data handling center buffer. Drawbacks to the use of the eraseable 
optical disk buffer include a high development risk because of the newness of 
the technology. This risk can be brought down if the "Optical Disk Buffer" is 
developed for both the on-board space station buffer application and the data 
handling center buffer application. This would happen because additional 
development funding could be supplied to support this common capability. 

Data Handling Center Results 

After assessing the various options to see how well they would fit into the 
data handling center buffer application the options were ranked from one to 
ten (ten being best) for each criterion. Table 9 presents the results of the 
ranking. Execept for magnetic disk in transfer rate and magnetic tape in 
access time, all three options scored well in all criteria. 

Magnetic tape scored well in the criteria of cost and development risk. The 
access time to data should not pose a problem if a first in, first out 
buffering scheme is used. A priority processing scheme is not possible with 
magnetic tape. 
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TABLE 9: DATA HANDLING CENTER BUFFER 
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Magnetic disk scored good marks in all criteria except transfer rate. This 
could be a problem if real time splitting of the data into 40 Mbit/sec data 
streams is not possible. 

Optical disk has the best figure of merit. It scored well in the performance 
and RAM criteria. Development risk is a major discriminator against optical 
disk. If optical disk is developed in parallel for both the data handling 
center and on-board space station high rate buffer applications the 
development risk could be significantly reduced because of the added 
development funding it could receive. 

Data’ Handling Center Buffer Recommendations 

It is recommended that advanced development efforts be focused on optical disk 
technology for buffering applications to reduce the perceived risk associated 
with this option. The development risk is further reduced by parallel 
development of the optical disk buffer for both the space station on-board 
buffer and the data handling center buffer applications. With sufficient 
emphasis this technology could be demonstrated and considered for the IOC 
configuration. If the optical disk development does not proceed as 
recommended, magnetic tape should be as the IOC option because of its 
maturity. However, optical disk development should continue for insertion into 
the growth configuration of the data handling center buffer application. 

Magnetic disk is not recommended as an option for the data handling center 
buffer applications because of the problems assocated with trying to split the 
TDRSS KSA link into 40 Mbits/sec stream. Splitting of packets into the 
separate streams is the most major of these problems. 
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Short Term Customer Data Archive 


Requirements for a centralized short term archive were developed by 
integrating the mission set average data rate over the appropriate period for 
both IOC and growth. The results from this analysis are shown below and range 
from the IOC amount to the growth amount. ' 

12 Hour On-line Storage 

110 - 179 Mbits/sec average rate 

5 - 8 X 10 12 bits capacity 

60 second access time (desired) 

7 day off-line storage 

110 - 179 Mbit/sec average transfer rate 
13 

7 - 10 X 10 bits capacity 
Less than 24 hours access time 

The options to be considered for the short term archive are: 

1 . Magnetic Tape 

2. Magnetic Disk 

3. Optical Disk 

Magnetic Tape 

A short term archive designed with magnetic tape devices can meet the capacity 
and transfer rate requirements, but there are problems that would arise from 
using magnetic tape that include: 

1. A long access time because of magnetic tapes sequential access 

characteristic. The access time can be improved if shorter tapes with less 
capacity are used but the tradeoff would be additional devices to make up 
the capacity requirement. The cost of such an arrangement, assuming tape 
drives with a capacity of 10** bits, would be in excess of 50 million 
dollars. This would be a costly solution to the access time problem of 
magnetic tape. 
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2. A magnetic tape solution to the short term archive would require many 
man-hours of labor to do such things as remove and replace tapes from the 
drives, degauss and inspect the tapes, and monitor the system. 

3. Access contention could be a problem if two users data are on the same 
magnetic tape and they request their data at the same time. 

Even though magnetic tape archives exist now it is not recommended that 
magnetic tape be used in this application. The major reason for this is the 
problems caused by the sequential access characteristic of the magnetic tape 
devices. 

Magnetic Disk 

Magnetic disk provides the random access characteristic that is needed to meet 
the access time requirement, but it fails to provide the necessary transfer 
rate. This problem can be worked around by splitting the data into streams of 
a manageable 40 Mbits/sec. To meet the capacity requirement would require 
about 140 drives, at a cost of $100,000 per drive. This amounts to 14 million 
dollars in hardware. Assuming these devices have removable disk packs that 
store 35 Gbits apiece, it would take about 2900 disk packs, at $900 each to 
meet the 7 day capacity requirement. That amounts to a media cost of 2.6 
million dollars. Because of the above reasons, it is not recommended that 
magnetic disk be used for the short term archiving applications. 

Optical Disk 

Write once optical disk provides the capacity, transfer rate, and random 
access needed for the short term archive. A currently operating RCA "Optical 
Disk Jukebox" installed at Marshall Space Flight Center has the following 
characteristics : 

13 

Storage for 10 bits 
50 Mbit/sec transfer rate 

5.5 second random access to any information 
Approximately $2,000,000 recurring cost 
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The characteristics of the optical disk jukebox are very close to the 12 hour 
on-line archiving requirements, thus making the optical disk jukebox concept a 
very attractive candidate for use as the short term archive. Major advantages 
to using the optical disk jukebox include: 

1. Meet the on-line capacity requirement in one device. 

2. Random access characteristic of optical disk. 

3. Lower cost than magnetic tape or magnetic disk. 

4. Low development risk. Present device characteristics almost match on-line 
requirments 

5. Data may be transferred to a permanent archive via removable media. 

6. Low media cost. 

Low media cost is an advantage optical disk has over other options. It is 
predicted in the options development report on mass storage that an optical 

9 

disk with a capacity of 533 X 10 bits will cost $30. To meet the seven day 

requirement about 190 disks are needed, which amounts to $5700. This is far 

less than the 2.6 million dollar media cost for the magnetic disk option. 

The present "Optical Disk Jukebox" is designed to hold 128 disks. A future 
"Jukebox" could be designed to hold all of the 190 disks required for the 7 
day archive, thus giving the 7 day archive an on-line capability. Also RCA 
has done a preliminary design of an automated "Optical Disk Library" . This 
library would use the same optical disks that are used in the "Jukebox". This 
would allow the optical disks to be transferred from the "Optical Disk 
Jukebox" to permanate storage in the "Optical Disk Library". 

Present optical disk transfer rate is too low to meet the requirement of 110 

Mbits/sec at IOC and 179 Mbits/sec at growth, but the risk is low that 

development efforts will provide the necessary transfer rate. 

Short Term Customer Data Archiving Results 

Table 10 presents the results of the option ranking for the short term 
archiving application. Optical disk is the clear choice for use as the mass 
store device for the 12 hour on-line and 7 day off-line customer data 
archiving applications. Major discriminators for optical disk and against 
magnetic tape and magnetic disk are performance, device cost, and media cost. 
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TABLE 10: SHORT TERM ARCHIVE 
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Optical disk also lends itself for use in a permanent archive. After serving 
its purpose in the short term archive, the optical disk may be removed and 
placed into a permanent archive. The life span of the optical disk media is 
reported to be greater than ten years, five time the life span of magnetic 
tape. 

Short Term Customer Data Archiving Recommendation 

It is recommended that the optical disk jukebox technology that was developed 
for Marshall Space Flight Center and Rome Air Development Center be used for 
short term archiving. Optical disk provides a low cost, low risk method of 
archiving the data for a short term, on-line with the possibility of 
transferring the media to a permanent archive, thus achieving cost 
effectiveness. Development effort should be focused on increasing the data 
rate and reducing the media cost. 
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On-Board Space Station Data Base Mass Storage 

For the purpose of this trade study, the IOC on-board space station data base 
management system (DBMS) will be sized to provide storage for: 


30 Mbytes 

Application programs 

50 Mbytes 

Telemetry data acquisition 

10 Mbytes 

Checkpoints 

5 Mbytes 

Engineering data 

5 Mbytes 

Procedures 

5 Mbytes 

Schedules 

144 Mbytes 

Growth margin 

249 Mbytes 

Total 


The full design characteristics for the on-board DBMS mass store are: 

9 

2 x 10 bits capacity 
10 Mbit/second transfer rate 
40 millisecond access time 

-12 

TBD BER (because of critical nature: 10 ?) 

Inside space station, 28.5° orbit f or > 10 years 
Space flight constrained phyisicals 
230 Rads/year 

The device options for the on-board space station DBMS are: 

1. Magnetic Disk 

2. Eraseable Optical Disk 

3. Magnetic Bubble Memory 

4. Semiconductor (CMOS) 

Other options such as read only optical disk, write-once optical disk, video 
tape, ect. may be used for other non-driving DBMS storage requirements 
applications such as entertainment and manual updates. 
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Magnetic Disk 


Present Winchester technology characteristics match the requirements of the 
DBMS mass store quite nicely, thus making magnetic disk an attractive 
candidate. The mass store designed with projected magnetic disk capabilities 
would have the following characteristics: 


Capacity: 
Transfer Rate: 
BER: 

Rad Hardness: 
Volume: 

Weight: 

Power: 

Recurring Cost: 
Risk : 

Reliability : 
Maintainability : 
Growth Potential: 


3 X 10 9 bits 
20 Mbits/sec 
< IQ' 10 
Good 

3 

600 inches 
50 lbs 

200 watts peak 

$ 11 , 000 * 

Low 

Good/device 
Modular replacement 
High 


* Space qualification cost not included 


Magnetic disk would provide more than adequate storage capacity and easily 
meet all but one of the design characteristics . Magnetic disks low score is 
in the area of bit error rate, but with improved techniques or coding schemes 
this will not be a problem. Space qualification of magnetic disk devises 
should not be a problem as there are flight qualified devices now available. 
Technology expandability and insertability look to be very good. 
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Optical Disk 


A DBMS mass store designed with the same eraseable optical disk technology 
discribed for the space station high rate data buffer would have the following 
characteristics : 


Capacity : 

Transfer Rate: 

Power: 

Volume: 

Weight: 

* 

Cost : 

Rad Hardness: 
Development Risk: 
Reliability : 
Maintainability : 


8 X 10 10 bits 
100 Mbits/sec 
200 Watts average 

3 

5100 inches 
200 lbs 

TBD (rough order of magnitude: $1,000,000) 
TBD (good) 

Medium high 

Consistent with a device with moving parts 
TBD 


# Price does include space qualification cost. 

Because eraseable optical disk is a new technology, the development risk is 
much higher than that of magnetic tape, but the technology for the "Optical 
Disk Buffer" has been demonstrated in the lab, and with proper funding the 
device can be developed and ready for use in the 1992 space station. 


15-46 



Magnetic Bubble Memory 


A DBMS mass store designed with magnetic bubble memory would have the 
following characteristics : 


Capacity : 

# of devices/subsystem: 
Transfer Rate: 

BER: 

Access Time: 

Rad Hardness: 

Volume: 

Weight: 

Power: 

Recurring Cost 
Risk: 

Reliability : 
Maintainability : 

Growth : 


9 

2 X 10 bits/system, 667 Mbits/subsystem 
125 

10 Mbits/sec/subsystem, 400 Kbits/sec/device 
10~ 1A 

10 milliseconds 

Poor to Good (depends on AF development effort) 

3 

750 inches /system 
25 lbs/system 
^ 600 watts 
$12,500 

Medium (depends on AF development effort) 

High (solid state device) 

Modular replacement 
High 


The DBMS mass store designed using bubble memory would meet all the 
performance requirements . The Air Force has a development effort to produce a 
space qualified bubble memory. 


Semiconductor: Complementarv-Metal-Oxide— Semiconductor (CMOS) 

CMOS was selected as the semiconductor candidate for a DBMS mass store because 
it has the best capacity /power, capacity /volume, and capacity/weight ratios of 
the semiconductor options. A mass store designed with 1 Mbit CMOS memory 
would have the following characteristics : 
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Capacity : 

ff of devices used: 
Transfer Rate: 

BER: 

Access Time: 

Rad Hardness: 
Volume: 

Weight: 

Power: 

Recurring Cost: 
Risk: 

Reliability : 
Maintainabi 1 ity : 
Growth : 


2 X 10 9 bits 
2000 

10 Mbits/sec 
Very good 
1 usec/device 

5 

10 Rads total dose 

3 

1000 inches 
100 lbs 

Depends on memory system design (around 100 watts) 

$62,400 

Low 

.Very High 

Modular Replacement 

Low to Medium, system designed to specification. 


Semiconductor is a good candidate for use as the DMS mass store because of its 
good performance figures, low risk, high reliability, and good physical 
specifications. The development cost for CMOS is low because of commercial 
demand for it in the marketplace. Even though CMOS is a volatile memory, 
non-volatility can be provided with a battery backup. 


On-Board Space Station DMS Mass Store Results 

After assessing the various options to see how well they would fit into the 
space station DBMS mass store the options were ranked from one to ten (ten 
being best) for each criterion. Table 11 presents the results of the 
ranking. Optical disk, magnetic disk, magnetic bubble memory, and CMOS 
semiconductor all are good candidates for the space station DMS. 
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TABLE 11: ON-BOARD SPACE STATION DBMS MASS STORE 
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The most significant discriminators between the options are: 


1. Development Risk 

2. Development Cost 

3. Reliability 

4. Power 

5. BER 

6. Special Considerations 


Magnetic disk provides the needed characteristics in current devices. This is 
a major factor in it's favor because it lowers development risk and 
development cost. Factors against magnetic disk include: moving parts that 
make it more unreliable than a solid state device and a higher bit error rate 
than that of a solid state device. 


Eraseable optical disk has very good performance characteristics . The 
projected characteristics will provide for growth. 

Bubble memory meets most of the requirements of the space station DBMS. 

Bubble memory would need the most development of the three candidates for the 
DBMS and current efforts in bubble memory development are not adequate to make 
bubble a low risk option. Bubbles main advantages are in the criteria of 
reliability and maintainability. 

CMOS semiconductor is a close second according to the figure of merit. It has 
good performance, high tolerance to radiation, low development cost, and low 
power requirements . As with magnetic disk, present CMOS devices can be used 
to build the DBMS mass store, thus giving CMOS a low development risk. There 
are no major factors against the use of CMOS as the DBMS mass store. 

Space Station DBMS Mass Store Recommendations 

It is recommended that eraseable optical disk be used for both IOC and growth 
space station DBMS mass store. Eraseable optical disk provides more than 
adequate storage capacity and transfer rate. Eraseable optical disk also 
lends itself to growth and modular replacement. 
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Magnetic Disk can also meet the design characteristic for the DBMS mass store 
requirement and should be used if optical disk development does not take place 
as recommended. 

CMOS semiconductor can also meet the requirements imposed by the DBMS but does 
not have the growth capability of magnetic disk. Bubble memory currently has 
too high a development risk to be considered for the IOC space station, but 
with proper development funding might make a good candidate for use on the 
growth space station. 

8. Conclusions 


Eraseable optical disk, because of its high performance and small size, is the 
recommended option for these application areas provided sufficient technology 
development and demonstration can be accomplished for IOC-Regardless of the 
final IOC configuration this technology should be developed for the growth 
space station. 

1. Space station high rate buffer 

2. Space station PLAN communication data buffer 

3. Polar-orbit platform data buffer 

4. Data handling center buffer 

5. Space station DBMS mass store 

If the eraseable optical disk devices are developed as recommended, the 
perceived development risk associated with this option will lessen. This is 
due to the increased development funding that can be supplied while still 
holding down overall development cost. The recommended development approach 
will bring about commonality between devices and spare parts that will 
further reduce costs . 

If development does not proceed as recommended then magnetic tape should be 
used for all the above application areas except the space station DBMS mass 
store, in which case magnetic disk should be used. 

Write-once optical disk should be used for the short term archiving 
application. The technology is already being used at Marshall Space Flight 
Center and Rome Air Development Center. It is a low cost, low risk option. 
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XVI . COMMAND AND RESOURCE MANAGEMENT 
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COMMAND AND RESOURCE MANAGEMENT 
TRADE STUDY REPORT 


1.0 TRADE STUDY DEFINITION 

1 . 1 Reason for Trade Study 

The command and resource management capability provided by the SSDS will be 
used extensively by the customer to functionally interact with his payload 
from his own institution/facility, including both on-board and ground 
elements. This trade study will identify and evaluate five candidate system 
designs for command and resource management that represent a spectrum of 
attractive concepts . 

1.2 Background 

The SSDS allocates Command and Resource Management to two major functions: 

2.0 Manage Customer/Operator Supplied Data, and 3.0 Schedule and Execute 
Operations. A command management and resource management system must be 
innovatively improvised to address a wide range of requirements . Requirements 
for command management include the following: 

o Authenticate Command Sender and Address. (Reference 1) 

o Determine Command Classification (Restricted, Constrained, or 
non-restricted) . (Reference 1) 

o Pass non-restricted commands and data directly to their destination 
with no further checking. (Reference 1) 

o Determine whether restricted and constrained commands are 
executable. (Reference 1) 

o Pass executable, restricted and constrained commands to their 
destination at appropriate times. (Reference 1) 
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o Attempt to resolve problems with not-executable commands. (Derived) 

o Return not-executable commands to sender. (Reference 1) 

o Allow customer to be able to cancel any command he initiated. 
(Derived) 

o Report all command disposition and status to sender. (Reference 1) 

o Provide for command data privacy. (References 1 & 2) 

o Process all commands in a manner consistent with customer real time, 

interactive operation. (Reference 1) 

o Support generation and real time change of stored command sequences. 
(Reference 1) 

o Support customer payload commanding. (Reference 1) 

o Make command entry and resolution user friendly. (Reference 1) 

o Enable customer payload control to be essentially the same as if the 
payload were in his own laboratory . (Reference 1) 

Requirements for resource management functions include the following: 

o Accept and verify operations requests from customers and station 
operators . (Reference 1) 

o Receive and confirm Major Event requirements from SSP. (Derived) 

o Negotiate Communications Requirements with NCC. (Reference 1) 

o Develop an optimum schedule consistent with constraints of power, 

crew task selection, communications bandwidth, and non-interference 
among payloads and Space Station systems. (References 1 & 2) 
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o Revise schedule in accordance with changing requirements , priorities, 
opportunities, and capabilities. (Reference 1) 

o Hold scheduled commands and dispatch at appropriate time. 

(Reference 1) 

o Support onboard, near term planning by the crew. (Reference 2) 

o Provide customers and operators data on Space Station resources and 

availability. (Reference 1) 

o Provide a single point of contact for customer communication 
reallocation requests. (Reference 1) 

o Accommodate a phased degree of Space Station autonomy. (Reference 2) 

o Make Resource Management user friendly. (Reference 1) 

o Ensure customer payload and core system do not interfere with each 
other and do not endanger the health and safety of the Space Station 
system. (Reference 1) 

Most of the above listed requirements are contained within the Customer 
Requirements for Standard Services (Reference 1) and/or Space Station RFP 
(Reference 2). Some additional requirements are included as derived from MDAC 
analysis . 

Communication (especially real time), power,, and crew time have been 
identified as being the limiting resources in resource management. A 
comprehensive analysis is used to identify preferred system design 
characteristics in this area. It is desired to minimize customer requirements 
(outside of initiating commands) through provisions for "customer transparent" 
checking, scheduling, etc. That is to say, the customer is kept oblivious of 
operations not concerning command initiation as much as possible. These 
features are to be maximized while drivers such as limiting resources are 
accommodated when selecting an optimum system. 
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1 . 3 Candidate System Options 


The five systems and their key features to be addressed by this trade study 
are shown in figures 1 through 5. System #1 represents full SSDS 
responsibility for payload functions and customer responsibility for 
determination of command executability . No command checking exists between 
the customer and payload. System #2 represents SSDS checking of all 
restricted/constrained commands. Single tier checking exists between the 
customer and payload along with support for customer interactive planning of 
the space station schedule. System #3 enables payloads and core systems to 
originate commands. It contains a single tier checking function onboard the 
spacecraft. The payload sends restricted and constrained commands out for 
approval. System #4 contains multiple tiers of restricted, constrained command 
checking. A separate path exists for non-restricted and executable commands. 
Each tier may dump a checked command to the "executable" path. Some checking 
may be performed by the customer prior to entering the SSDS. The payload must 
reject improperly checked commands. System #5 provides apriori resolution of 
problem commands and multiple tier checking through its integrated command 
checking and scheduling. Again, this system incorporates a separate path for 
non— restricted and executable commands. It also provides for a scheduling 
service at the customer's request. 

1 . 4 Issues 


The following items represent major areas of concern relative to making value 
judgements on the candidate systems capability for command and resource 
management and are incorporated into the trade study criteria (See section 4): 

a. What is the risk that present or new technology can meet development, 
production (producibility), and cost/scheduling requirements? 

b. What level of standardization/commonality should be achieved? 

c. How much growth/technology insertion potential should be instituted? 
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gure 1. System #1 - Customer Responsible for Determining Command Executabili ty 
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All commands flow directly from the customer • Full duplex error check on uplink commands, 

to the payload. 

Checking and resource management onboard. • Single tier checking. 

Check can command core systems. 

Payloads and core systems can originate commands. 
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FIGURE 3. System #3 - Payload Sends Restricted, Constrained Commands Out For Approval 
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Figure 4. System #4 - Multiple Tiers of Restricted, Constrained Command Checking 



FIGURE 5. System #5 - Integrated Command Checking and Scheduling 




d. What level of performance in the areas of reliability, 
maintainability and responsiveness is needed to be attained? 

e. What will be the cost effectivity in the development (nonrecurring) , 

unit (recurring) and life cycle (training, maintenance and operation) 
operations? ‘ 

f. Which resource drivers will be most significant in determining the 
optimum system trade offs? 

g. What factors are to be included for a realistic sensitivity analysis 
of all candidate systems? 

h. Which systems carry more weight from a customer accommodation 
perspective? 

i. What is the most cost-effective integration scheme that will satisfy 
performance requirements , buildup sequence, scheduling, and checking 
of application functions? 

1 • 5 Trade Study Criteria 

The Command and Resource Management systems will be evaluated in two separate 
steps. The first step addresses the degree to which the system meets 
requirements . The applicable requirements and their sources are: 

A. Does the customer receive assurance of error free delivery of his 
command to his payload? 

B. Does the customer know whether a command is delivered? (Reference 1: 

1 . 1 . 8 ). 

C. Can the customer cancel any command he initiated? 


D. Is resolution performed on not executable commands (e.g., develop 

time slip requirements to enable a formerly not executable command to 
become executable) (Reference 1: 6. 1.6. 2). 

E. Does the customer receive reasons for not executable commands? 
(Reference 1: 7. 3. 4.1). 

F. Are all not executable commands negotiable by the customer? 

G. Are all not executable commands returned to the customer? (Reference 
1: 6. 1.3.1) 

H. Is the customer (sender of commands) and address authenticated? 
(Reference 1: 1.1.4 & 6.1.4). 

I. Can classification be determined on all commands (e.g., restricted, 
constrained, or non-restricted)? (Reference 1: 6.1.6 & 7.2.5). 

J. Is there assurance that all commands will be properly classified? 

K. Are non-restricted commands passed through the SSDS without any 

further checks imposed on them? (Reference 1: 6. 1.6. 3). 

L. Can a customer functionally interact with his payload in the same 

manner as if the payload were in his laboratory and enable him to 
conduct his experiment(s) from his own institution/facility 
(Reference 1: 6.1.3). 

M. Does SSIS provide adequate servicing of command processing so that 
the customer requirements is minimized within the command management 
system framework? (Reference 1: 1.1.4, 1.1.8, 6.2.1) 

N. Can command privacy be maintained at all times? (Reference 1: 

2 . 2 . 2 ). 
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O. Is there adequate security against disclosure of command information 

to unauthorized personnel? (Reference 1: 0-3). 

P. Are restricted and constrained commands logically separated from the 

general uplink? (Reference 1: 7. 3. 4.1). 

Q. Does the system support customer interactive planning of the Space 

Station schedule? (Reference 1: 7.2.1 & 7.2.2. 1). 

R. Is customer allowed to enter his commands in bulk? (Reference 3). 

S. Is real-time interaction available? (Reference 1: 6.2.1, 6.2. 1.2 & 
6. 2. 1.3). 

The second step addresses the following qualitative evaluation criteria: 

Cost - What relative cost level is associated with the buildup, operation and 
future growth of the system? 

Schedule — What is the probability for successful implementation of the 
system within the available seven year total program schedule? 

Performance - Is the level of performance satisfactory? Performance includes 
real time command (no substantial increase in response time over that 
necessary for communications - estimated to be approximately one second) and 
the ability of a system to handle throughput. 

Resource Effectiveness - Are spacecraft resources U 3 ed efficiently, i.e, to 
what degree can a system facilitate resource management? 

Customer Accommodation - Can the customer be accommodated effectively, i.e., 
to what extent can a given system maximize the value of customer payload 
product? 

FMEA - What failure mode effects exist, i.e., what is the relative potential 
for catastrophic failure modes for a given system? 
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Resource Availability - Is there a suitable availability of resources 
including considerations such as the location of required resources, 
criticality of required resources, and the type of required resources? 

Flexibility - Does the system have adequate flexibility to handle future 
growth and technology upgrade? 
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2.0 Methodology 


The basic approach which will be utilized for the trade study on candidate 
command and resource management systems consists of the following: 

o Fully describe the systems to be traded showing their intrinsic 
features . 

o Modify systems to fully meet all application requirements if possible 
without altering each system's basic essence. 

o Evaluate the candidate systems relative to qualitative evaluation 
criteria specifically designed for the command and resource 
management trade study . 

o In the future, a computer simulation model should be developed to 
facilitate the sensitivity analysis. This would greatly enhance a 
capability to gain further insight into all possible acceptable 
combinations with regard to the practical operation. 

3.0 Results 


As indicated in Section 1.4, the trade study was conducted in two steps. 

The requirements evaluation is shown in Table 1. The ratings against 
requirements are: Yes, No, Partially, and Maybe, indicated by Y, N, P, and 

?. Systems #4 and #5 are shown to successfully meet all criteria. Systems #2 
and #3 will require some modification so that all criteria can be met. System 
#1 will not be able to meet all the criteria without substantial 
modifications. Note that modification required for systems #1, 2, and 3 would 
change these systems intrinsically. 

The evaluation of the systems against the qualitative evaluation criteria is 
shown in Table 2. The ratings made were as follows: High, Low, and Medium, 

indicated by H, L, and M. Systems #4 and #5 appear to handle most of the 
criteria the best. With limited modification these two systems would be able 
to score well with respect to all criteria. Systems #1, #2 and #3 would 
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Table 2 

Qualitative System Evaluation 


Evaluation System #1 System #2 System #3 System #4 System #5 * 

Criteria |H |M |L |H |M |L |H |M |L |H |M |L |H |M |L | 


COST 

f 

1 

1 

SCHEDULE 

I 

1 

(7 year prob- 

1 

ability) 

1 

I 

PERFORMANCE 

1 

1 

-Real time 

1 

Command* 

1 

-Ability to 

|X 

Handle Through 

1 

put 

1 

I 

RESOURCES 

1 

1 

(Can facilitate 

1 

resource man- 

1 

agreement) 

1 

1 

CUSTOMER 

1 

1 

ACCOMMODA- 

1 

TION*** 

1 

POTENTIAL 

1 

1 

FOR CATAS- 

1 

TROPHIC 

1 

FAILURE 

1 

MODE 

1 

SYSTEM** 

1 

1 

AVAILABILITY 

1 

OF RESOURCES 

1 

1 

GROWTH/ 

1 

1 

TECHNOLOGY 

1 

UPGRADE 

1 

Overall Ratings 

1 



* No substantial increase in response time over that necessary for 
communication: + 1/2 second. 

** Location, criticality and type of resources are considerations. 
*** Maximize value of customer payload product. 
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require extensive modification to score well against the qualitative 
criteria. This would mean these three systems require alteration from their 
basic intrinsic features. 

Systems 4 and 5 appear to be intrinsically adequate in satisfying the 
requirements and qualitative evaluation criteria. Systems 1, 2 and 3 fail in 
totally satisfying all of the requirements and qualitative evaluation criteria 
based on their individual intrinsic features. Therefore, they are not 
acceptable as designed. 

4.0 Conclusions, Recommendations and Issues 


A. Further trade study effort should be performed on systems 4 and 5 
through a sensitivity analysis. 

B. Systems 1, 2 and 3 need not be explored further unless modifications 
to alter their basic intrinsic features is decided upon as being 
acceptable . 
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SPACE COMMUNICATIONS 


1.0 Introduction 

End to end communications service for any user information precesses across a 
number of communications links as well as undergoing processing at a number of 
nodes during the flow towards the "sink". The end to end aspect includes on 
board (POP/COP/SS ) connectivity, the link to (and from) the ground, the NASA 
distribution network (NASCOM, land satellite service, local links), as well as 
level "0" processing for format/error protect ion/ routing/queue service, signal 
processing, and also the linkage of engineering support information (event, 
time, environmental conditions and/or settings, etc) to the actual payload 
data. 

The information itself may also suggest different modes of handling, i.e. some 
may require precedence handling (e.g., emergency events), some may be 
constrained to real time delivery as opposed to delayed delivery; some may 
require a high degree of error protection while other information (e.g., 
video) may be sufficiently robust that error handling doctrine may be minimal. 

The growth patterns which are anticipated as the SSIS matures, (see Task 4, 
SSDS report), must be accommodated by the communications system in a 
relatively straightforward manner. Therefore, there must be a level of 
flexibility and adaptivity (near real time and also as events are scheduled) 
built into the basic architecture. In addition, the Space Station will 
generate video and audio information which will require distribution both 
on-board and to ground facilities (users, POCC's, public affairs, etc). This 
information, in conjunction with core data and payload data, are the 
components of the communications portion of SSIS. Command and control, video 
and audio, and program uploads are the primary contributory components of the 
"forward" link to the Space Station. The COP and POP communications needs are 
dominated by experiment data, however, command and control are also required 
for the uplinks to these platforms. 
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Finally, processing at various locations in the end to end chain, if not 
adequately addressed, can cause delivery delays, create multiple levels of 
processing which affects S/W (and H/W) cost and development uncertainty, and 
perhaps create an institutional rigidity which will be difficult to change as 
the Space Station program evolves. It should be an objective that processing 
points in the end to end chain, be located where ground level processing can 
be most efficient. Level "0" and "1A" processing is discussed in Task 4 
Section 7.0 (Ground SSDS definition). 

This section concentrates on space communications, identifies various high 
level options for efficient use and implementation of the space to ground 
links, and via comparative tradeoff identifies the most attractive options. 

2.0 Ground-Space Architecture 

In order to support the maturing of the Space Station program and the likely 
changes in emphasis, mission experiments, and the presence of payloads on the 
COP and POP platforms, as well as the Space Station, the TDRSS return (down) 
link is addressed here as the primary link to ground. The discussion below 
considers the Ku band (single access link) as the primary down trunk because 
of its 300 MBPS capacity; the availability of S band links (single and 
multiple access) are implied but except for information partitions and 
therefore processing simplification, these add minimal capacity to the 
required band width. 

The primary emphasis below is on the use of TDRSS, TDRSS enhancements, or 
augmentation to the down link to accommodate special loading or service 
demands . 


2. 1 Ground to Space Architecture Options 

The following list of options have been identified: 

a. 1,2, 3, 4 satellite TDRSS configurations. 

b. TDRSS augmented by enhancements or TDAS. 
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c. TDRSS augmented by a commercial satellite utilizing a combination of 
TDRSS and ACTS technology. 

d. TDRSS augmented by direct downlink to the DSN. 

e. All users required to provide for their requirements in excess of 
TDRSS capacity. 

The capacity characteristics of the TDRSS links are shown in Table 1. 


TABLE 1 - TDRSS DATA RATE CAPACITIES 


SERVICES AND PARAMETERS 

MA 


SSA 


KSA 

FORWARD LINK SERVICES 






QUANTITY OF LINKS PER TDRS 

1 


2 


2 

TOTAL LINKS FOR THE TDRSS 

1 


4 


4 

RETURN' LINK SERVICES 






QUANTITY OF LINKS PER TDRS 

20 


2 


2 

TOTAL LINKS FOR THE TDRSS 

20 


4 


4 

FORWARD LINK 






MAXIMUM USER DATA RATE 

10 

KBPS 

300 

KBPS 

25 MBPS 

RETURN LINK 






MAXIMUM USER DATA RATE 

50 

KBPS 

3 

MBPS 

300 MBPS 


PER 

; TDRS 

TOTAL 

FOR TDRSS 

TRACKING LINKS 






ONE-WAY DOPPLER 

10 


10 



TWO-WAY RANGE AND DOPPLER (MA) 

1 


2 



TWO-WAY RANGE AND DOPPLER (SA) 

4 


6 




NOTE: THIS TABLE IS BASED ON 2 SATELLITES DEDICATED TO TDRSS SERVICE; 

SOURCE: SPACE NETWORK TDRSS DATA BOOK, APRIL '85. 
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2.1.1 Four Satellite (TDRS) Configuration 


TDRSS utilization in 1,2,3, or 4 satellite configurations requires examination 
of the impact of Zone of Exclusion (ZOE), hardware impact and operations 
effect. Table 2, based on projected locations for these various TDRSS 
options, summarizes these considerations. In summary, the ZOE means that any 
data collected during this period cannot be "sent down", thus suggesting two 
general strategies. The first is to continue to collect such data, buffer 
until TDRSS returns to view, and then transmit. This means, for example 
(using the 15% exclusion zone) that the down link must handle, in the worst 
case, 1.15 (the normal) data rate. This leaves unresolved such questions as 
to whether a First In-First Out (FIFO) protocol is to be followed once TDRSS 
accessibility is restored, or whether a level of source data throttling should 
be introduced during ZOE. These are issues which can best be addressed by 
mission oriented tradeoffs. 

Another issue is the fact that multiple TDRSS "birds" suggest the use of at 
least two TDRSS antennas on the user platform so that maximum use can be made 
of the available channels. In this case, the handover process becomes a 
factor, probably requiring covering signals from two (or more) TDRSS platforms 
(using the forward link for establishing a reference). Signal acquisition and 
re-acquisition (how long? how to point?, how to know which antenna/TDRSS is in 
view?) are the implementation considerations. 


Finally, one general factor in the architectural equation is the desire to 
time share (COP, POP, and Space Station) the linked TDRSS resources; event and 
access scheduling are essential to service all three platform types. 

The TDRSS capacity is listed in Table 1; the major downlink (Ku, SA) is rated 
at 300 MBPS. One of the major factors in the data rate is the modulation 
scheme (QPSK). By the use of a different modulation method (eg. 8-ary), the 
data rate can be substantially increased. 

A 50-100% increase (depending on whether the channel is encoded or not) is 
theoretically possible; the technology is reasonably well known. 
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TABLE 2 - TDRSS OPTIONS VS ZOE 


# TDRSS 

APPROX. 

ZOE 


CHARACTERISTICS 

SATELLITES 

LOCATION 

% OUTAGE 



1 

J 

41 U 

APPROX. 

A) 

Large data buffers and/or throttling 



(40-50)% 

B) 

during ZOE; 

Re-acquisition required 

2 

41 W 

15% 

A) 

Throttle back/buffer data during ZOE 


171 U 


B) 

Have East-West handover problem: 




C) 

One - SS antenna requires fast slow rate 
and fast acquisition 
Two - SS antennas minimize data loss 
during handover. 

3 

41 U 


A) 

Increased data capacity 50% of orbit 


61 W 

15% 

B) 

Complex antenna handover procedures 


171 W 



(could run at 300 MBPS 85% of time through 
1 & 2, using third TDRSS to dump ZOE data 
also at 300 MBPS). 

4 

41 U (2) 

15% 

Doubled information capacity 85% of 


171 W (2) orbit; East-West handover problems; changes at 

ground terminals antenna system. 

Basic Source: TDRSS User Guide 

2.1.2 TDAS Augmentation of TDRSS 

The TDAS satellite, which is now in the planning phase could be available in 
the early phases of the Space station program (e.g., 1995-2000). A comparison 
with TDRSS is shown in Table 3. It is obvious that it offers substantially 
more capacity than TDRSS (approx. 1 GBPS vs 300 MBPS for the single access 
return (down) link) and projects the use of steerable regional or spot beam 
antenna which could reduce the terrestrial network load by directing data to 
regional locations. 
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TABLE 3 - TDRSS vs TDAS CAPABILITY SUMMARY 
(SOURCE: TDAS FOR THE 1990' s; 5/31/83) 
STI REPORT TO GODDARD 


TDRSS 


TDAS 


• 1 FORWARD CHANNEL • 2 FORWARD CHANNELS 

• 20 RETURN CHANNELS (SYSTEM MAX) • 10 RETURN CHANNELS PER S/C - LINK 

MULTIPLE ACCESS GAIN INCREASES BY 4.5 dB 

• BEAMFORMING AT GROUND • ONBOARD BEAMFORMING 


• 2 K— (OR S— )BAND PER S/C 


SINGLE ACCESS 


• DATA RATES TO 300 Mbps 


• K— (OR S-) BAND 

• 5 W-BAND PER S/C 

• 1 LASER 

• DATA RATES TO 1 Gbps 


SPACE-TO-GROUND 


• SINGLE BEAM ANTENNA 
- 1 FIXED LINK 


• Ku BAND TO WHITE SANDS 

• DOMSAT RELAY 


• MULTIPLE BEAM ANTENNA (5 FIXED 
HORNS, 4 STEERABLE) 

- 5 FIXED LINKS 

- 1 MOBILE LINK 

• ONBOARD TWO-WAY SWITCH 

• RETAIN Ku AT WHITE SANDS, USE 
Ka AT ALL OTHER SITES 

• NO DOMSAT RELAY 


CROSSLINK 


• NONE 


• 1 FORWARD PER S/C (25 Mbps) 

• 1 RETURN PER S/C (1.8 (Gbps) 

• LASER OR 60 GHz 


The problems are technical uncertainty and programmatic (will it be funded and 
when will it be available). Network management complexity will also be a 
factor in addressing operational level decisions. 
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2.1.3 COMSAT/ACTS Augmentation of TDRSS 


TDRSS augmented by a commercial communications satellite capability on the 
Space station (or the POP or COP), where that satellite could use the multiple 
access and antenna pointing technology of the Advanced Communications 
Technology Satellite (ACTS) Program, could offer an increase in down link 
capacity and allow for connection to regional or user facilities. ACTS 
technology is being developed under NASA contract, and is to be tested in the 
1988-1990 time frame. A potential application of ACTS technology is to 
support the distribution of TDRSS return link data from White Sands to 
regional user sites. 

2.1.4 Direct Downlink To DSN 

Augmenting TDRSS by links to a network such a3 the Deep Space Network is 
possible for off loading the TDRSS. DSN is not a high capacity network, but 
could be used for additional coverage for moderate data demands. However, at 
best it might be used for emergency down links, rather than as an integral 
part of the SSIS communications structure. 

2.1.5 User Provided Downlink 

Customers might want to or be required to provide for direct down links from 
the Space Station (or COP or POP) rather than depend on the SSDS/SSIS 
constraints. This alternative would affect the platform communications 
requirements and also offset other auxilliary areas such as power budget, 
electro-magnetic interference patterns, antenna and structural factors. 

2.2 Conclusion 

The changing traffic profile of the projected experiments makes the future a 
little unclear. However, the projected satellite TDRSS configuration 
(essentially two each stationed at East and West stations) would probably be 
adequate for the IOC plus some reasonable growth. This is a relatively low 
technical risk solution, with the caveat that the ground terminal and network 
would have to be modified to support both the traffic increases and the 
antenna footprints. Careful scheduling to avoid conflict between POP, COP, 
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and Space Station is essential to take advantage of this robust TDRSS downlink 
capability . 

If real time delivery delays cannot be met by this approach, then the addition 
of antenna steering (as in TDAS and/or ACTS technology) to delivery to 
regionally located data handling centers, must be considered. 


3.0 DOWNLINK TRANSMISSION OPTIONS 

The discussions below describe options, some tradeoff criteria, and finally 
the advantages and disadvantages of each, as related to the link 
organization. The primary criteria although implicit, is in the ability to 
accommodate changing requirements over the mission life and on a near real 
time basis to accommodate special conditions. The discussion below also 
assumes that audio and video information will be digitized, and that data 
using the return (downlink) TDRSS links will probably fit into three 
categories. The first is facilities/housekeeping telemetry data, which 
requires modest capacity (e.g., 5MBPS or less). The second is continuous and 
relatively high rates (e.g., 10-50 MBPS payload data); and, the third is 
payload data reflecting more modest requirements (e.g. 100 KBPS to 5 MBPS). 

The question of packets for all data or a combination of packets with 
implications of 5-10% overhead (e.g. using a modified CCSDS format) and 
virtual/direct connection is considered. Packets impose a processing load 
(and associated delay); virtual connections require an adequate quality 
channel (within SSIS), and dynamic allocation of virtual channels to minimize 
scheduling and control of the experimental payload activity. 

Packetization requires that onboard processing and the counterpart location in 
the ground network have responsibility for keeping the discipline of the 
packetized data; a virtual connection assumes that the end addressee will 
collect and process the data - i.e. the POCC/PI or data handling center, and 
requires minimal overhead in the SSIS information flow. However, the virtual 
connection implies no error control in the path between source and sink. The 
options below address these possibilities. 
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3.1 Tradeoff Considerations 

The trade study options presented in the discussion on uplinks and downlinks, 
must be evaluated keeping in mind the particular characteristics of the 
transmitted data. Each option must not only provide for current data rates 
but must be evaluated as to their ability to handle increased data rates as 

the SSIS grows. In addition to planned events, the data transmission formats 
should be flexible enough to handle various emergency or contingency 
situations as they arise. With SSIS channel bandwidths at a premium, 
efficient channel utilization is an important consideration when evaluating 
the various options. Other factors such as routing complexity, data overhead, 
and the ability to redistribute data loads must also be considered. Finally, 
the availability of technology to support the various options must be 
considered; in particular, new technology presents risk for the implementer 
and, implicit, is the impact of uncertain costs for new technologies. 

3.1.1 TIME MULTIPLEX SCHEMES 

a. DEDICATED TIME SLOTS (FIXED FRAME) 

This scheme is characterized by the fixed boundary within each frame which 
separates the low rate data packets from the high rate data stream (virtual 
connection), see Figure 4.1. Each frame has the same ratio of low rate data 
to high rate data. The scheme is tailored to the data characteristics and 
allows simple handling procedures since there are well defined data 



Synch Fixed Boundary 


Figure 4-1. Time Multiplex Schemes — Fixed Frame 
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boundaries. The fixed boundaries within each frame however, do present the 
difficulty with channel capacity utilization, and provides limited flexibility 
for contingencies and growth. 

Frame synchronization is very important, so that a small overhead exists to 
determine and acquire synch, at the start of each frame. 

b. DYNAMIC ALLOCATION 

This scheme is similar to the previous scheme in that each frame contains a 
boundary between the high rate data stream and the low rate data packets. The 
difference is that the position of the boundary from frame to frame is 
dynamically allocated according to the scheduled data rate requirements, see 
Figure 4.2. The scheme requires a coordination packet at the beginning of 
each frame to identify where the boundary is located. The 

coordination/signalling packet notifies the ground entry node when a change in 

the dynamic boundary is to occur; thus it requires a coordinating hand shake, 
which takes a minimum of time equal to round trip delay plus processing. The 
scheme provides efficient use of channel capacity and there is inherent 
flexibility for contingencies and growth. As a result of the dynamically 
changing data boundary however, relatively complex data handling procedures 
are required. 


Dynamic 



Dynamic 

Boundary 


Figure 4-2. Time Multiplex Schemes — Dynamic Allocation 
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c . TOTALLY PACKETIZED 


In this scheme both the low rate data and high rate data are packetized and 
then multiplexed into the frames. As a result the scheme allows the use of 
standard protocols and formats. A significant overhead is required with this 
scheme in order to identify the contents and destination of each data packet. 
Discussions of various packet candidates are made in the Task 3, Section IV, 
Communication Standardization Trade Study, but in general the use of a 
standard packet (e.g. CCSDS) would simplify network transversal and 
intermediate processing. It is not apparent at this point, that low rate 
payload data and high data rate, continuous data should be enveloped into the 
same packet format. Thus, in the latter case, the overhead penalty would be 
more closely in balance with the amount of data; in the former case, 
processing complexity is less than with a non-standard packet format and 
structure . 

3.1.2 Channel Allocation Scheme #1 

The downlink capabilities in this scheme have been divided into three links. 
The first is the S— band link which will be reserved for core data. The 
Ku-band, I channel (150 Mbps) will be used for the second link and will be 
reserved for high rate or bulk data. The third link will be the Ku-band, Q 
channel (150 Mbps), and will be reserved for additional experimental data 
and/or video. As a result of the well defined data boundaries the scheme 
allows for simple data handling procedures. The disadvantages of this scheme 
include possible poor channel capacity utilization and poor flexibility for 
change contingency and growth. 


3.1.3 Channel Allocation Scheme 02 

Downlink data in this scheme will be divided between two channels. The first 
channel will be the S-band link and will be reserved only for core data. The 
Ku-band link will be the second link and will be dynamically allocated. This 
scheme conbines well defined data boundaries and reasonable channel capacity 
utilization. There is an inherent flexibility for contingencies and growth 
and data handling procedures are only moderately complex. 
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3.1.4 Channel Allocation Scheme #3 


This scheme utilizes the Ku-band link for all data transmission with the 
S-band link reserved to smooth peak loads. As a result of dynamic allocation 
there is inherent flexibility and good channel capacity utilization. The 
primary disadvantage ta this scheme is that the data handling procedures 
become quite complex. 

3.2 Conclusions 

1. Amongst the three possibilities discussed under Time Multiplexed options, 
the dynamic allocation is the most flexible and gives a relatively 
efficient channel usage mode. The dedicated time slot approach is 
somewhat inflexible and a major overhead penalty is required to support a 
fully packetized channel. Therefore, option b (Dynamic Allocation) is 
recommended at this time. The method of coordination between the Space 
Station commmunications subsystem and the ground terminal will have to be 
analyzed to determine complexity and capability required at the ground 
entry terminal. 

2. It is premature to determine how to partition the downlinked (return) 
traffic which will use TDRSS. If throttling during excessive traffic 
periods is acceptable, then allocation method #3 is not necessary. 
However, more operational/mission user liaison is required to make any 
specific recommendation at this point. 

4.0 UPLINK TRANSMISSION OPTIONS 

The uplink to the spacecraft, could be considered in a number of categories: 
Space Station - uplink to include command data, uplinked event information 
data, program uploads data, and voice and video information; Co-orbiting 
Platform (COP) - If it is connected directly to ground via TDRSS, then the 
uplinks are for data only; if Space Station acts as a relay to the COP for 
uplinking, then the Space Station will be responsible for "parsing" the 
information stream and relaying the data to the COP; Polar Orbiting Platform 
(POP) - direct uplink through TDRSS for command, data and program uploads. 
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It is assumed that a packet format will be used for commands and program 
uploads data; audio and video should not require that format. 

4.1 Channel Allocation Scheme #1 

This scheme utilizes the S-band uplink for all core commands and utilizes the 
Ku-band uplink for user commands and video. The scheme possesses well defined 
data boundaries and inherent flexibility for contingencies and growth. The 
data handling procedures are only moderately complex. 

4.2 Channel Allocation Scheme #2 

This scheme employs the Ku-band link for all uplink information with the 
S-band link reserved for overflow at peak times. There is great flexibility 
with this scheme and good channel capacity utilization. With all data 
multiplexed on one channel complex data handling procedures are required. 

4.3 Conclusion 

Channel Allocation Scheme #1 is the lower risk approach. The partitioning of 
the uplink into Ku-Band and a clearly defined user group and the S-Band for a 
clearly defined user (core station commands) makes for a clear organization . 
The only concern would be to examine the user command requirements, based on 
the changing user data base, and determine whether there might be conflict 
with the uplink video requirements . Judicious scheduling could eliminate that 
concern. 

5.0 INTERNAL (PLATFORM) ARCHITECTURE OPTIONS 

It is recognized that the Onboard Local Area Networking Trade Study, Task 3, 
Section V, also addresses architecture options, however this section addresses 
only partitioning concepts of the three classes of information (data, voice 
and video) from a communications perspective. 

The major components of the information which traverses the SSIS are data, 
video and audio. The on-platform communications is also composed of those 
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elements, although, in the use of the Space Station, part of this information 
does not go to ground but is used to support on board and corollary space 
operations . 

Three options exist; a distribution system (switched or bus/ring which does 
not partition between the three classes of information, a system which is 
partitioned so that each class traverses its own path, and finally a hybrid 
where perhaps video and audio are on one distribution system while data is 
distributed via a data bus (quasi-LAN) throughout the craft and to video 
interfaces . 

Examining these options it is necessary to characterize the information 
traffic. Video if digitized, will require major bandwidth allocation - thus a 
standard broadcast quality, color, TV picture will require approximately 80 
MBPS. Through various compression techniques, a highly acceptable picture can 
be achieved at approximately 22 MBPS. A similar condition exists for 
audio/speech - i.e. a straightforward (PCM) digitization technique yielding 
"toll" quality speech requires about 64 KBPs but the use of a different 

algorithm (CVSD) affords good, understandable quality of 16/32 KBPS. Although 
other voice digitization techniques (e.g. OPC) offer reasonable quality at 
somewhat lower rates, the 16/32 KBPS rate represents an easily achievable 
design, the 32 KBPS is used on STS, and voice loading is not a major 
contributer to the SSIS loading. Further, video and voice are rather robust - 
i.e. there is sufficient redundancy so that random errors will have little or 
no effect on intelligibility, resolution, etc. In addition, they are 
continuous (not bursty) sources. 

The data tends to fit into three categories: core or facility data tends to 

be relatively low rate - e.g. sensors typically have rates between 10 bps and 
5 KBPS. In addition, the information in this area will probably continue 
throughout the life of the space craft and its appearance will be highly 
predictable (e.g. once/minute, once/hour, etc.). Payload data tends to fit 
into two categories: relatively continuous, high rate, data such as would be 

derived from mappers and relatively modest rate sources such as materials 
processing . 
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Further, an assumption is made that data will require protection - i.e. error 
detection/correction coding; video and audio do not require that protection. 

5.1 Bus Network vs Switched Distribution Structures 

J 

Although a switched structure is feasible it does have certain disadvantages 
which mitigate against it, at this stage of the SSIS development. First, it 
tends to be a centralized function and even though redundancy techniques are 
possible, this becomes a point of concern in terms of single point failure. 
Second, recognizing that the SSIS/SSDS will evolve as missions change and 
perhaps module changeover is required for the Space Station, a switched 
structure is more difficult to rewire and to reconfigure in a large sense. 

A bus or distributed LAN, if properly designed, allows for adding or deleting 
terminals, payload sources, processing elements (such as data base units, 
memory elements) and also is more flexible as space assembly of a Space 
Station is considered. Further, by using by-pass techniques or even a network 
of smaller networks, single point failure is not a serious factor. 


5.2 Bus/Network Options 

The audio/video distribution can either be digital or analog on the Space 
Station; it is assumed that when that information merges with SSDS data on an 
external RF link that the information will be digitized. 

If all information on the Space Station were digitally transmitted on the 
craft, even with compression techniques, the rates (based on traffic 
projections) would be well in excess of 100 MBPS, (depending on scheduled 
events, could be 200 MBPS) which taxes the state of the bus technologies 
available - even that of fiber optics. Although it is anticipated that the 
technology will advance over the next five years, a conservative approach is 
to assume separate data and audio/video distribution networks. It is also 
assumed that an analog distribution system, on board, using CCTV or broad 
band/FDM techniques, is low risk and modest cost, and could be acceptable for 
TV and audio interconnect service. 
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The primary concern at this juncture is that of the format of the on board 
data networks. Three generalized options appear and are listed below: 

a) All data transmitted on parallel on board SSDS busses utilizing a 
packetized format. 

♦ 

b) Parallel data buses with different characteristics . 

• Core data bus utilizing a packetized format for low rate 
transmission. 

• User data bus using virtual connections for high rate/bulk data 
transmission . 

• Direct memory access data bus for bulk transfer of stored data or 
bulk uploads. 

c) Another option would combine data, voice, video, in a digital format 
on the same bus structure; however, the very high rates which would 
be required would require some major technology improvements. 

In the first option, the packetized format might be different than that used on 
an RF link, because the internal network connection performance is much more 
predictable . 

The use of a standard format has the advantage of simplifying processing. 
However, the use of a single network structure for all SSDS information might 
cause problems where high volume, continuous users gain access, denying access 
to lower rate users. To avoid this, either timeout or precedence is required 
and this complicates the processing. Further, there is a significant overhead 
imposed on all users (i.e. everyone uses packets). 

In the second option, the core data bus would allow SSDS information to be 
transferred internally and to/from RF interfaces in a relatively timely and 
predictable manner. The "user data" bus would be set up for a specific 
experiment or group of experiments and would not impose a packet type overhead 
penalty on this data stream. This "virtual connection" has the value of being 
relatively efficient, but does require set up for the experiments which would 
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fit into this category. The other element of this option is that bulk 
transfer could use a direct memory access into assigned buffers or memory 
fields. This removes a potential heavy traffic load from the internal, common 
users SSDS structure, and obviously is a high speed/low connect time service. 

Of the two primary options, b (above) is the most attractive for the following 
reasons : 

• The internal distribution system is most closely tailored to the 
characteristics of the users. Thus, by segregating by user groups, 
it is relatively efficient. 

• It does not impose the risk that high volume data users will either 
be limited in the time that they may occupy the channels, or that 
there is a substantial packet processing penalty to be paid by the 
high volume users (where the stream would have to be broken into 
packet sizes regardless of the data characteristics) . 

• It affords adequate service for low speed/low rate users, payloads, 
and sensor telemetry information. 

• The ability to accommodate major changes in payload requirements is 
only limited by the implemented bandwidth. 

• Low priority users are not "locked out". 

5.3 Conclusions 

Option c), where voice, video, and data appear on the same bus is not very 
practical from two viewpoints: 

1. Digital video is exceedingly bandwidth consuming and would require a 
major improvement in the technology. 

2. Traffic generated by different uses exhibits characteristics 
(distribution, occupancy, etc.) which are very different. 
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Option a) and b) address a distribution structure where video and voice are 
either on separate (or perhaps) on a common distribution system. 

Option a) combines all data on one bus structure; this means that low priority 

users or short duration data needs might not get adequate service if long 
duration users (e.g., heavy use users) occupy the bus. 

Option b) partitions these data groups and thus allows for a design which is 

closer to these user needs by class of needs, discussed at the end of the last 

paragraph, above. Therefore, option b) is the presently recommended system. 
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